Method and system for providing secure access to private networks with client redirection

ABSTRACT

Improved approaches for providing secure access to resources maintained on private networks are disclosed. The secure access can be provided through a public network using client software of client-server software and/or with file system software. Multiple remote users are able to gain restricted and controlled access to at least portions of a private network through a common access point, such as an intermediate server of the remote network.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. patent applicationSer. No. 10/060,792, filed Jan. 29, 2002, which claims the benefit ofU.S. Provisional Patent Application No. 60/350,097, filed Nov. 2, 2001.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to client-server computing and, moreparticularly, to client-server computing for securely accessingresources over a network.

2. Description of the Related Art

Network browsers (browser applications), such as Netscape Navigator orMicrosoft Explorer, allow users of client machines to request andretrieve resources from remotely located server machines via theInternet. These network browsers can display or render HyperText MarkupLanguage (HTML) documents provided by the remotely located servermachines. Additionally, browsers are able to execute script programsembedded in the HTML documents to provide some local functionality.

Conventionally, network browsers are used to access public networks,such as the Internet. Private networks are normally protected byfirewalls so that network browsers residing on computing machinesoutside the private network are not able to gain access to any resourceson the private network.

While firewalls are effective at protecting against external access toprivate networks, there is often the need for external persons orbusinesses to gain at least limited access to the private networks ofother persons or businesses. For example, a supplier of parts to abusiness customer may be able to better serve their business customer byhaving access to information (e.g., inventory levels or orders)maintained on the private network of the business customer. Oneconventional approach is to allow the supplier's machine to access theprivate network through the firewall via a public network. This providesa “hole” in the firewall that seriously compromises the security of theprivate network. Hence, this conventional approach is normally notpermitted if security is an important concern. Another conventionalapproach is to establish a Virtual Private Network (VPN) with thesupplier's machine. Here, the supplier's machine is also able to accessthe private network through the public network and the firewall, but alldata transmissions are encrypted. Some firewalls support VPNs andprotocols providing the encrypted communications, such as Point-to-PointTunneling Protocol (PPTP), can be used. While VPNs offer remote secureaccess, they are difficult to arrange, configure and manage. Each VPNmust also be provided for each external person or business given accessto the private network. Still further VPNs are costly and each VPNprovides some security exposure to the entire private network.

Thus; there is a need for improved approaches to providing secure remoteaccess to resources maintained on private networks.

SUMMARY OF THE INVENTION

The invention pertains to improved approaches for providing secureaccess to resources maintained on private networks. The secure accesscan be provided through a public network using client software ofclient-server software, and/or with file system software. Multipleremote users are able to gain restricted and controlled access to atleast portions of a private network through a common access point, suchas an intermediate server of the remote network. One example of a remotenetwork is a private network.

The invention can be implemented in numerous ways, including as asystem, method, device, and a computer readable medium. Severalembodiments of the invention are discussed below.

In one method embodiment, a network connection request is received, thenetwork connection request is redirected, and data are sent towards theintermediate server. The method can permit secure remote access to theremote network.

The network connection request can be received on a computer on a localnetwork. The network connection request can be initiated by a clientapplication of a client-server application. The client application canbe on the computer. The network connection request can include adestination on a remote network. A server application of theclient-server application can be on the remote network.

The network connection request can be redirected within a Windows socketlayer on the computer. This can include redirecting the networkconnection request with the namespace provider (e.g., utilized fordomain name service lookups on the remote network) and the layeredservice provider (e.g., utilized for redirecting the data of the clientapplication from the local network to the remote network). The networkconnection request can be redirected away from a transport serviceprovider (e.g., a TCP/IP transport service provider) of the computer.The network connection request can be redirected to an intermediateserver in the remote network. The intermediate server can perform thenetwork connection request on behalf of the computer. The redirectingcan be based on one or more of: a name of the client application, achecksum of the client application, a version of the client application,a server of the destination, and a port of the destination. Prior to theredirecting, the network request can pass through one or more of: theWinsock dynamic link library and the Winsock 2 dynamic link library. Thenetwork connection request can be redirected to the intermediate serverin the remote network via at least a proxy on the computer.

The data of the client application can be sent from the computer towardsthe intermediate server. A secure sockets layer (SSL) can encryptcommunication between the computer and the intermediate server. The dataof the client application can be sent from the intermediate servertowards the server application. Various embodiments send the data of theclient application from the intermediate server towards the serverapplication, or allow this to occur by software or hardware outside ofthe embodiment. The data of the client application can be sent throughat least a local address and a local port of the computer prior tosending the data of the client application towards the intermediateserver.

In some embodiments, a visual cue can be provided to indicate a secureconnection between the client application and the intermediate server.The namespace provider and the layered service provider can beautomatically installed on the computer and/or uninstalled from thecomputer.

In another method embodiment, a network connection request is received,the network connection request is redirected, and data are received fromthe intermediate server. The method can permit secure remote access tothe remote network.

The network connection request can be received on a computer on a localnetwork. The network connection request can be initiated to a filesystem on a remote network. The network connection request can include aname of the file system.

The network connection request can be redirected using a transportdriver interface on the computer, and may further use a namespaceprovider. The redirecting can capture network file system traffic. Thenetwork connection request can be redirected away from a transportdriver (e.g., a TCP/IP transport driver) on the computer. The networkconnection request can be redirected to an intermediate server in theremote network. The intermediate server performs the network connectionrequest on behalf of the computer. The redirecting is based on one ormore of: a destination server and a destination port. Prior to theredirecting, the network connection request can pass through at least atransport driver interface filter.

At the computer data of the file system from the intermediate server canbe received. A secure sockets layer (SSL) can encrypt communicationbetween the computer and the intermediate server. The data of the filesystem can be transferred between the intermediate server and the filesystem on the remote network. Various embodiments transfer the data ofthe file system between the intermediate server and the file system, orallow this happen via hardware or software outside of the embodiment.

In some embodiments, the transport driver interface can be automaticallyinstalled on the computer and/or uninstalled from the computer.

The various aspects, features, embodiments or implementations of someembodiments described above can be used alone or in variouscombinations.

Some embodiments can be implemented in software, but can be implementedin hardware or a combination of hardware and software. Some embodimentsof the invention can also be embodied as computer readable code on acomputer readable medium. The computer readable medium is any datastorage device that can store data which can thereafter be read by acomputer system. Examples of the computer readable medium includeread-only memory, random-access memory, CD-ROMs, DVDs, magnetic tape,optical data storage devices, and carrier waves. The computer readablemedium can also be distributed over network-coupled computer systems sothat the computer readable code is stored and executed in a distributedfashion.

Computer code in various embodiments can be implemented in hardware,software, or a combination of hardware and software.

Other aspects and advantages of the invention will become apparent fromthe following detailed description taken in conjunction with theaccompanying drawings which illustrate, by way of example, theprinciples of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be readily understood by the following detaileddescription in conjunction with the accompanying drawings, wherein likereference numerals designate like structural elements, and in which:

FIG. 1A is a block diagram of an information retrieval system accordingto one embodiment of the invention.

FIG. 1B is a block diagram of an information retrieval system accordingto another embodiment of the invention.

FIG. 2A is a block diagram of an intermediary server according to oneembodiment of the invention.

FIG. 2B is a block diagram of a remote access system according to oneembodiment of the invention.

FIG. 3 is a flow diagram of request processing according to oneembodiment of the invention.

FIG. 4 is a flow diagram of authentication processing according to oneembodiment of the invention.

FIG. 5 is a flow diagram of access privilege processing according to oneembodiment of the invention.

FIG. 6 is a flow diagram of operational privilege processing accordingto one embodiment of the invention.

FIG. 7 is a flow diagram of detailed external authentication processingaccording to one embodiment of the invention.

FIGS. 8A and 8B are flow diagrams of file access request processingaccording to one embodiment of the invention.

FIGS. 9A-9C are flow diagrams of web resource request processingaccording to one embodiment of the invention.

FIG. 10 illustrates a diagram of an information retrieval systemaccording to one embodiment of the invention.

FIG. 11 is a flow diagram of URL modification processing according toone embodiment of the invention.

FIG. 12 is a flow diagram of script modification processing according toone embodiment of the invention.

FIGS. 13A and 13B are flow diagrams of script modification processingaccording to another embodiment of the invention.

FIG. 14 is a flow diagram of email request processing according to oneembodiment of the invention.

FIG. 15 is a flow diagram of mail operation processing according to oneembodiment of the invention.

FIG. 16 is a flow diagram of authentication processing according to oneembodiment of the invention.

FIGS. 17A and 17B illustrate an example of a computer system that may beused in accordance with some embodiments of the invention.

FIG. 18 is a block diagram of some embodiments of a secure applicationmanager according to one embodiment of the invention.

FIG. 19 shows a block diagram of Winsock applications and a Windowssocket layer according to one embodiment of the invention.

FIG. 20 shows another block diagram of Winsock applications and aWindows socket layer according to one embodiment of the invention.

FIG. 21 shows a block diagram of queues between the secure applicationmanager proxy and Winsock applications according to one embodiment ofthe invention.

FIG. 22 shows a block diagram of installation packaging according to oneembodiment of the invention.

FIG. 23 shows a block diagram of applications and a transport driverinterface on a client computer on a local network according to oneembodiment of the invention.

FIG. 24 shows a block diagram of a generic operating mode forredirecting file system network connection requests according to oneembodiment of the invention.

FIG. 25 shows a block diagram of a mode with custom handlers forredirecting file system network connection requests according to oneembodiment of the invention.

FIG. 26 shows a flow diagram for redirecting network connection requestsaccording to one embodiment of the invention.

FIG. 27 shows a flow diagram for redirecting network connection requestsaccording to another embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The invention pertains to improved approaches for providing secureaccess to resources maintained on private networks. The secure accesscan be provided through a public network using a standard networkbrowser. Multiple remote users are able to gain restricted andcontrolled access to at least portions of a private network through acommon access point.

The solution can enable users, such as employees, contractors orpartners, to access resources resident on a private network in a securemanner while being remotely located from a direct connection to theprivate network. The solution provided by some embodiments of theinvention is not only easily set up and managed, but also able tosupport many remote users in a cost-effective manner.

Embodiments of this aspect of the invention are discussed below withreference to FIGS. 1A-27. However, those skilled in the art will readilyappreciate that the detailed description given herein with respect tothese figures is for explanatory purposes as the invention extendsbeyond these limited embodiments.

FIG. 1A is a block diagram of an information retrieval system 100according to one embodiment of the invention. The information retrievalsystem 100 includes a network 102, client machines 104 and 106, anintermediary server 108, remote servers 110 and 112, a private network114, and private servers 116 and 118. The network 102 serves as acommunication medium through which the client machines 104 and 106, theintermediary server 108 and the remote servers 110 and 112 cancommunicate. The network 102 is, for example, a data network which caninclude the Internet, a wide area network, or a local area network. TheInternet refers to a global network of interconnected computers. Theprivate network 114 also serves as a communication medium through whichthe intermediary server 108 and the private servers 116 and 118 cancommunicate. The network 114 is also a data network. Often the privatenetwork 114 is associated with an entity and thus employees operatingcomputing devices on the private network 114 are able to communicatewith the private servers 116 and 118. For example, the private network114 can be referred to as a corporate network or an intranet. However,access to the private network 114 by an outside computing device istypically limited by a firewall (not shown). The intermediary server 108is permitted to communicate with the private network 114 through thefirewall. Here, to the extent a client machine (requestor) is authorizedand permitted, the intermediary server 108 communicates with the privatenetwork 114 on behalf of the client machine (requestor). Theintermediary server 108, in effect, controls the extent to which itallows outside computing devices to access the private network 114.

According to some embodiments of the invention, requests for contentresiding on the private servers 116 and 118 can be received from theclient machines 104 and 106. As used herein, “content” is anyinformation or resource that can be stored on a server and retrieved bya client. Typically, the content is embodied as an electronic file andcontains text and/or images. Often, the client machines 104 and 106operate browser applications that facilitate requesting and retrieval ofcontent over the network 102 and the private network 114. In such cases,the content is often returned to the browser application as abrowser-viewable document (e.g., markup language document, webpage,etc.) so that the browser application can display the same. The clientmachines 104 and 106 communicate with an intermediary server 108.Initially, the intermediary server 108 determines whether the clientmachines 104 and 106 seeking the content are authenticated and permittedsuch access to the private network 114. Following successfulauthentication and permission verifications, the intermediary server 108then, in turn, accesses the private servers 116 and 118 residing on theprivate network 114 on behalf of the client machines 104 and 106. Oncethe intermediary server 108 obtains the requested content from theprivate servers 116 and 118, the intermediary server 108 can directlyreturn the requested content to the client machines 104 and 106 or canfirst modify the requested content and then deliver it to the clientmachines 104 and 106.

The modification to the requested content by the intermediary server 108can take a variety of forms. As one example, the intermediary server 108can insert a toolbar into the requested content before delivery to theclient machines 104 and 106. As another example, the intermediary server108 can alter the hyperlinks within the requested content so as to pointto an intermediary server (e.g., the intermediary server 108). Variousother tasks can be performed on the requested content by theintermediary server 108. Additionally, the information retrieval system100 can also support centralized storage at the intermediary server 108of server stored information. The server stored information is oftenreferred to as “cookies,” though cookies are conventionally stored onclient machines.

Although the information retrieval system 100 illustrated in FIG. 1Adepicts only a pair of client machines, a pair of remote servers, asingle intermediary server and a pair of private servers, it should beunderstood that the information retrieval system 100 can support manyclient machines and many server machines. It should also be understoodthat the information retrieval system 100 can also support multipleintermediary servers.

FIG. 1B is a block diagram of an information retrieval system 150according to one embodiment of the invention. The information retrievalsystem 150 is, for example, a more detailed implementation of theinformation retrieval system 100 illustrated in FIG. 1A.

The information retrieval system 150 makes use of the Internet 152 andclient machines 154 and 156 that couple to the Internet 152 throughwired or wireless means. Typically, the client machines 154 and 156operate client-side applications, such as a network browser or a mailapplication. When requestors (users) of the client machines 154 and 156desire to access remote resources, resource requests are sent from theclient machines 154 and 156 through the Internet 152 to an intermediaryserver 158. Typically, the communications between the client machines154 and 156 and the intermediary server 158 are secured by an encryptiontechnique (e.g., Secure Socket Layer (SSL)). The intermediary server 158provides access to an intranet 160. The resources being requested by theclient machines 154 and 156 reside within the intranet 160. Since afirewall typically limits or precludes external access to the intranet160, the intermediary server 158 must be permitted to communicate withthe intranet through the firewall 162. The intranet 160 typicallyincludes various different types of resources that can be accessedelectronically. Typically, these resources are stored on server machinesthat couple to, or form part of, the intranet. As shown in FIG. 1B, theintranet 160 couples to, or includes, an authentication server 164, aweb server 166, a mail server 168, a file server 170 and a log server172. Hence, a given client machine can access any one of the servers164-172 residing within or on the intranet 160 by way of theintermediary server 158. Consequently, a given client machine canrequest and receive resources residing on the web server 166 using anetwork browser application. As another example, the given clientmachine can access the mail resources residing on the mail server 168using a client-side mail application. As still another example, thegiven client machine can access the file server 170 residing within oron the intranet 160 to obtain, store or view electronic files thereon.

The intermediary server 158 is configured to ensure that access to theintranet 160 via the intermediary server 158 remains protected. In thisregard, the requestors that are seeking to access resources or contentresiding on the intranet 160 must be authenticated. The authenticationcan utilize the authentication server 164 residing within or on theintranet 160. In this regard, native authentication techniques utilizedby the intranet 160 can be used in authenticating a requestor at theintermediary server 158. Still further, the intermediary server 158 canbe configured by an administrator such that different requestors (e.g.,users of client machines) can be given different access privileges todifferent resources (e.g., servers) within or on the intranet 160. Thelog server 172 allows the storage of log information pertaining toaccess requests to the intranet 160 at the intermediary server 158. Thelog information can be provided on an application level basis such thatit is more user-discernable.

FIG. 2A is a block diagram of an intermediary server 200 according toone embodiment of the invention. The intermediary server 200 is, forexample, suitable for use as the intermediary server 108 illustrated inFIG. 1. The intermediary server can also be called an intermediateserver.

The intermediary server 200 includes various processing modulestypically implemented by computer program code executed by a processingdevice utilized by the intermediary server. More particularly, theprocessing modules of the intermediary server 200 include a web server202 and a protocol handler 204. The web server 202 couples to clientmachines through a link 206 (via a network) and the protocol handler 204couples to remote servers through a link 208 (via a network). The webserver 202 and the protocol handler 204 also communicate with oneanother as well as with various supporting modules and a data storagedevice 210. The data storage device 210 provides persistent ornon-volatile storage for various data items being maintained by theintermediary server 200. Typically, for each user or requestorassociated with a client machine, the data storage device providesseparate storage.

The processing modules include an authentication manager 212 and anaccess manager 214. The authentication manager 212 managesauthentication processing which serves to determine whether therequestor is who they say they are. The authentication processing can belocal or external to the intermediary server 200. For example, externalauthentication can be provided by an authentication server within aprivate network (e.g., authentication server 164). The access manager214 provides access limitations to the various resources on the privatenetwork. Namely, different requestors can be assigned different levels,types or areas of access privileges. For example, requestor A can accessserver X but not servers Y and Z, and requestor B can access server Yfor read-only and not servers X and Z.

The intermediary server 200 also includes a content transformer 216,which is another processing module that is used to parse requestedcontent received from a remote server and then modify the content inpredetermined ways.

Another processing module that the intermediary server 200 might includeis a cookie manager 218. The cookie manager manages “cookies” such thatthose being received from a remote server are stored to the data storagedevice 210 and those “cookies” previously stored in the data storagedevice 210 are delivered to the remote server at appropriate times. Moregenerally, “cookies” refer to server stored information. Such serverstored information is often set by a remote server and used for session,state or identification purposes.

FIG. 2B is a block diagram of a remote access system 250 according toone embodiment of the invention. The remote access system 250 operatesin a client-server environment to allow users of clients to gain accessto resources at remote servers. In particular, the remote access system250 includes a network browser 254 and a mail client 256. The networkbrowser 254 and the mail client 256 are client applications that operateor run on client machines. Typically, a user or requestor will interactwith these one or more client programs to request resources located onthe remote servers. The network browser 254 and the mail client 256couple to an intermediary server 252 over secure links or connections.The intermediary server 252 also couples to the remote servers througheither secure or unsecure connections or links. The intermediary server252 can support connections to various different servers, such asservers found on private networks. One example of a private network is acorporate network. The servers illustrated in FIG. 2B include a webserver 258, an email server 260, a Windows file server 262, a UNIX fileserver 264, an authentication server 266 and a log server 268.

The intermediary server 252 includes a Secure Socket Layer (SSL) 272that provides encryption handling for the connection or link with theclient applications prior to reaching a front-end protocol handier layer270. The front-end protocol handler layer 270 includes a plurality ofprotocol handlers to handle the different types of incoming protocolsthat may be utilized by the various client applications. As shown inFIG. 213, the front-end protocol handler layer 270 includes separateprotocol handlers for the protocols of HTTP, IMAP, SMTP, POP, and MAPI.After the appropriate protocol handler has been utilized for an incomingrequest, other functional modules within the intermediary server 252 canthen be utilized. In particular, an access manager 274 can determinewhether the requestor associated with the incoming request is permittedthe type of access being requested. An authentication manager 276 candetermine whether the requestor is able to be authenticated. A contenttransformer 278 can perform transformation of the content of thereceived request or the requested response provided by the remoteserver. A system administration manager 280 allows a systemadministrator to interact with the intermediary server 252 to configureaccess privileges, system configuration and login features.

The intermediary server 252 also includes back-end protocol handlers282. The back-end protocol handlers 282 provide the appropriate protocolfor outgoing and incoming communications with respect to a particularserver. The layer of back-end protocol handlers shown in FIG. 2Bincludes protocol handlers for the protocols of: HTTP, IMAP, SMTP, POP,SMB, NFS, NIS, RADIUS, LDAP, and NT. To the extent that an incomingprotocol to the intermediary server 252 differs from an outgoingprotocol from the intermediary server 252, the content transformer 278can perform the protocol transformations (e.g., translations). Stillfurther, the intermediary server 252 includes a data store 284, a logmanager 286, and a data synchronization manager 288. The data store 284can provide temporary or semi-permanent data storage for the variouscomponents of the intermediary server 252. For example, a local recordfor authentication purposes can be stored for each of the clients orrequestors in the data store 284. In addition, session identifiers, orcookies, for the clients or requestors can also be stored in acentralized fashion in the data store 284. The data synchronizationmanager 288 is a module that enables coupling of one intermediary serverwith another intermediary server to provide fault tolerance. Hence, ifone intermediary server fails, then, through a link 290, the failingintermediary server can couple to an operating intermediary server toprovide some or all of the operations typically associated with anintermediary server. The log manager 286 is provided to enableapplication level logging of various access requests that are madethrough the intermediary server 252. The log formed by the log manager286 is stored in the log server 268.

FIG. 3 is a flow diagram of request processing 300 according to oneembodiment of the invention. The request processing 300 is invokedwhenever a request from a requestor is received by an intermediaryserver, such as the intermediary server 108 illustrated in FIG. 1A, theintermediary server 158 illustrated in FIG. 1 B, the intermediary server200 illustrated in FIG. 2A or the intermediary server 252 illustrated inFIG. 2B.

The request processing 300 begins with a decision 302 that determineswhether the received request is a system login request. When thedecision 302 determines that the received request is a system loginrequest, then the request processing 300 attempts to authenticate 304the requestor. The authentication can be performed locally or remotely.Additional details on authentication are provided below. Thereafter, adecision 306 determines whether the requestor has been authenticated.When the decision 306 determines that the requestor cannot beauthenticated, then the login attempt fails and a login page can bereturned 308 to the requestor. The login page facilitates login retry bythe requestor. Following the operation 308, the request processing 300is complete and ends for the case in which the login request failed.

Alternatively, when the decision 306 determines that the requestor isauthenticated, then a session identifier is returned 310 to therequestor. The requestor can refer to a client device or the user of theclient device depending on context. The session identifier is used insubsequent requests to the intermediary server as long as the session isactive. Additionally, an initial access page is returned 312 to therequestor. From the initial access page, the requestor is able to accessvarious resources available on a private network. Following theoperation 312, the request processing 300 is complete and ends for thecase in which the login request was successful.

Besides the processing of login requests, the request processing 300also operates to process all other requests for remote access via theintermediary server. Hence, when the decision 302 determines that thereceived request is not a system login request, then a decision 314determines whether the received request has a valid session identifier.The received request would have a valid session identifier if therequestor has already been authenticated (i.e., logged into theintermediary server) and the session is still valid. Hence, when thedecision 314 determines that the session identifier associated with thereceived request is not valid, then access to the intermediary server isdenied and the login page can be returned 308 to the requestor.Alternatively, when the decision 314 determines that the sessionidentifier is valid, then a decision 316 determines whether the sessionhas timed-out. When the decision 316 determines that the session hastimed-out, then access to the intermediary server is denied and thelogin page can be returned 308 to the requestor. Here, if the requestorhas an invalid session identifier or the session has timed-out, therequestor is forced to login to be authenticated.

On the other hand, when the decision 316 determines that the session hasnot timed-out, then the requestor is permitted to access the privatenetwork via the intermediary server. Thereafter, depending upon the typeof access the requestor is seeking to make, additional processing isperformed to ensure that the requestor gains access to only thoseresources deemed appropriate and intended. In particular, with respectto the request processing 300, access privileges associated with therequestor are obtained 318. The access privileges indicate whichresources the requestor is entitled to access. Next, a decision 320determines whether the particular access type associated with thereceived request is permitted. When the decision 320 determines that theaccess type associated with the received request is not permitted, thenan access denied page is returned 322 to the requestor. Alternatively,when the decision 320 determines that the access type of the receivedrequest is permitted, then the received request is permitted 324 to beprocessed. Here, the processing of the received request enables therequestor to access (e.g., view, retrieve, etc.) the protected resourcesfrom the private network. Following the operations 322 and 324, therequest processing 300 is complete and ends with the received requesthaving been processed only when access is deemed permitted.

FIG. 4 is a flow diagram of authentication processing 400 according toone embodiment of the invention. The authentication processing 400 is,for example, processing associated with the authentication operation 304illustrated in FIG. 3.

The authentication processing 400 begins with a decision 402 thatdetermines whether a local record for the requestor (user) exists. Whenthe decision 402 determines that a local record for the requestor doesexist, then a decision 404 determines whether local or externalauthentication is required. Here, the local record indicates whetherlocal or external authentication should be performed. Besides anindication of whether local or external authentication should beperformed, a local record can also store other useful information, forexample, requestor's (user's) name, time last logged in, account status,etc. When the decision 404 determines that local authentication is to beperformed, a password provided with the login request being processedfor authentication is hashed 406. Hashing is the transformation of astring of characters into another string of characters referred to as a“key” that represents the original string. A hash function can performthe hashing operation. Hashing is often performed in the encryption anddecryption context.

Next, a decision 408 determines whether the hashed password matches astored hash password. When the decision 408 determines that a match ispresent, then the authentication is deemed successful 410.Alternatively, when the decision 408 determines that a match is notpresent, then the authentication is deemed to have failed 412. Further,when the decision 408 determines that there is no match, then an accessfailure can also be logged 414 in a log. In one embodiment, the log canbe provided by a log server. The logging 414 of the access failure canprovide application-level information that facilitates understanding ofthe nature of the access failure that occurred when later viewing thelog. Following the operations 410 and 414, the authentication processing400 is complete and ends with the authentication either succeeding orfailing depending on whether the login request contains the correctpassword.

On the other hand, when the decision 402 determines that a local recordfor the requestor does not exist, then a decision 416 determines whethera local setting is required. A system setting can be used to indicatewhether or not a local record is required. An administrator can use sucha system setting to limit access to only those users having localrecords. When the decision 416 determines that a local setting isrequired, then the authentication is deemed to have failed 412 becausethere is no available local record. Again, the access failure can belogged 414. Alternatively, when the decision 416 determines that a localsetting is not required, or when the decision 404 determines thatexternal authentication is to be performed, then an address and type ofexternal authentication server (EAS) to be used for the authenticationare obtained 418. Different processing is typically performed withdifferent types of external authentication servers. Normally, theseexternal authentication servers are already provided within the privatenetwork for purposes of performing authentications. Typically, there isa system setting that indicates a particular external authenticationserver to be used. Hence, the authentication processing 400 can make useof the native authentication provided by such external authenticationservers. The discussion below pertaining to FIG. 7 provides additionaldetail on different types of external authentications.

Next, a decision 420 determines whether the external authentication hasbeen successful. Here, external authentication is performed dependingupon the particular type of external authentication that has beenindicated. When the decision 420 determines that external authenticationis not successful, then the authentication is deemed to have failed 412.Additionally, the access failure can be logged 414 as previouslydiscussed. On the other hand, when the decision 420 determines that theexternal authentication has been successful, then the authentication isdeemed to be successful 422. Following the operation 422, theauthentication processing 400 is complete and ends with the requestorbeing authenticated.

FIG. 5 is a flow diagram of access privilege processing 500 according toone embodiment of the invention. The access privilege processing 500 is,for example, processing performed by the decision 320 of FIG. 3. Namely,the access privilege processing 500 determines whether the access typebeing requested is permitted by a particular requestor. In effect, theaccess type provides various criteria that can be used to limit accessby requestors. With respect to the embodiment shown in FIG. 5, thecriteria includes source Internet Protocol (IP) address, time-of-day,and operations.

The access privilege processing 500 begins with a decision 502 thatdetermines whether the source IP address associated with the receivedrequest (i.e., the requestor) is authorized. When the decision 502determines that the source IP address associated with the receivedrequest is not authorized, then the access privilege processing 500denies access 504. Here, to reduce risk of unauthorized access, theaccess privilege processing 500 ensures that only those IP addresses ofknown requestors are able to access the private resources.

When the decision 502 determines that the source IP address isauthorized, then a decision 506 determines whether the time at which therequest is being made satisfies a time-of-day access limitation.Typically, this limitation can be configured for all requestors orseparately for each requestor. Here, the intermediary server can beconfigured, if desired, to permit access to private resources onlyduring certain time periods. This, for example, can permit access onlyduring business hours or other limited hours. When the decision 506determines that the time of the received request is not within thetime-of-day permitted, then the access privilege processing 500 deniesaccess 504.

When the time associated with the received request is determined 506 tobe within the time-of-day permitted, a decision 508 determines whetherthe particular operation associated with the received request ispermitted. Here, the incoming request can request various differentoperations to be performed with respect to the private resources. Thesevarious different operations tend to vary with type of application beingprovided. The decision 508 can operate to limit the operations permittedto be used by different requestors. When the decision 508 determinesthat the operation being requested is not permitted, then access isdenied 504. On the other hand, when the decision 508 determines that therequested operation is permitted, then access is permitted 510.Following the operations 504 and 510, the access privilege processing500 is complete and ends.

FIG. 6 is a flow diagram of operational privilege processing 600according to one embodiment of the invention. The operational privilegeprocessing 600 is, for example, performed by the decision 508illustrated in FIG. 5. It should also be noted that the operationalprivilege processing 600 performs the requested operation when suchoperation is determined to be permitted, and thus can be associated withthe operations 320 and 324 of FIG. 3.

The operational privilege processing 600 begins with a decision 602 thatdetermines whether a file browsing operation has been requested. Whenthe decision 602 determines that a file browsing operation has beenrequested, then a decision 604 determines whether file browsing isenabled for the requestor. When the decision 604 determines that filebrowsing is not enabled for the requestor, then access is denied 606 andthus the operational privilege processing 600 ends. Alternatively, whenthe decision 604 determines that file browsing is enabled for therequestor, then a decision 608 determines whether a read or writeoperation is being requested. When the decision 608 determines that awrite operation is requested, a decision 610 determines whether writeaccess is permitted. In one embodiment, the decision 610 determineswhether write access is permitted by the particular requestor making therequest. When the decision 610 determines that write access is notpermitted, then access is denied 606 and thus the operational privilegeprocessing 600 ends. Alternatively, when the decision 610 determinesthat write access is permitted, then write request processing isperformed 612 to carry out the received request. Following the operation612, the operational privilege processing 600 ends with the requestedoperation having been performed.

On the other hand, when the decision 608 determines that a readoperation is being requested, a decision 614 determines whether readaccess is permitted. In one embodiment, the decision 614 determineswhether read access is permitted by the particular requestor making therequest. When the decision 614 determines that read access is notpermitted, then access is denied 606. Alternatively, when the decision614 determines that read access is permitted, then read requestprocessing is performed 616 to carry out the requested operation.Following the operation 616, the operational privilege processing 600 iscomplete and ends with the requested operation having been performed.

On the other hand, when the decision 602 determines that the requestedoperation is not a file browsing operation, a decision 618 determineswhether the requested operation is a web browsing operation. When thedecision 618 determines that the requested operation is a web browsingoperation, a decision 620 determines whether the server associated withthe web browsing operation is accessible to the requestor. When thedecision 620 determines that the server is not accessible to therequestor, then access is denied 606. In one embodiment, theintermediary server can maintain a list of servers that are accessibleby particular requestors. This enables the intermediary server tocontrol the resources that particular requestors are able to browse byserver names. For example, although a private network may includenumerous servers, requestors are able to be individually restricted toaccessing only certain servers. Alternatively, when the decision 620determines that the server associated with the web browsing operation isaccessible to the requestor, then the web browsing request processing isperformed 622. In other words, the requested web browsing operation isperformed 622 because the requestor was entitled to access theparticular server. Following the operation 622, the operationalprivilege processing 600 ends with the requested operation having beenperformed.

On the other hand, when the decision 618 determines that the requestedoperation is not a web browsing operation, then a decision 624determines whether the requested operation is an email operation. Whenthe decision 624 determines that the requested operation is an emailoperation, then a decision 626 determines whether email (electronicmail) is enabled for the requestor. When the decision 626 determinesthat email is not enabled for the requestor, then access is denied 606.Here, the intermediary server is able to control access to emailoperations by particular requestors. Alternatively, when the decision626 determines that email is enabled for the requestor, the emailrequest processing is performed 628. In other words, the requested emailoperation is performed because the requestor had suitable privileges toperform the operation. Following the operation 628, the operationalprivilege processing 600 ends with the requested operation having beenperformed.

Still further, when the decision 624 determines that the requestedoperation is not an email operation, then a decision 630 determineswhether the requested operation is some other operation that ispermitted by the intermediary server. Here, the other operation can beany suitable operation that is facilitated by the intermediary server.In effect, the other operation can represent a generic operation that isavailable on the intermediary server. The other operation can also referto a local operation being performed by the intermediary server withoutaccess to a private network. Examples of local operations can varywidely but can include: adding bookmarks, adding, editing or deletinglocal records, altering file shares, etc. However, the other operationcould also be an operation performed within the private network. Whenthe decision 630 determines that the requested operation is one of theother operations, then a decision 632 determines whether the otheroperation is permitted. When the decision 632 determines that therequested operation is not one of the other operations that arepermitted, then access is denied 606. Alternatively, when the decision632 determines that the other operation is permitted, then the otherrequest processing is performed 634. Following the operation 634, theoperational privilege processing 600 is complete and ends with the othertype of operation having been performed.

On the other hand, when the decision 630 determines that the requestedoperation is not one of the other operations that are permitted (by therequestor), then the operational privilege processing 600 ends withouthaving performed the requested operation. Here, since the requestedoperation was unsupported by the operational privilege processing 600,the requested operation is not processed (i.e., it is blocked) at theintermediary server.

FIG. 7 is a flow diagram of detailed external authentication processing700 according to one embodiment of the invention. The detailed externalauthentication processing 700 is, for example, detailed processingassociated with the decision 420 illustrated in FIG. 4. The detailedexternal authentication processing 700 supports a variety of differenttypes of external authentication systems, including: Network InformationSystem (NIS), Remote Authentication Dial-In User Service (RADIUS),Lightweight Directory Access Protocol (LDAP), and NT domain. Hence, theexternal authentication performed for the intermediary server can useany of a variety of native authentication approaches that a privatenetwork might provide.

The detailed external authentication processing 700 begins with adecision 702 that determines whether the external authentication server(EAS) is NIS. When the external authentication server is NIS, then a NISrecord is read 704. Then, the password provided with the login requestis hashed 706. The hashed password is compared 708 with that providedwithin the MS record. A decision 710 then determines whether the hashedpasswords match. When the passwords do match, the authenticationsucceeds 712. When the passwords do not match, the authentication fails714.

On the other hand, when the decision 702 determines that the externalauthentication server is not NIS, a decision 716 determines whether theexternal authentication server is RADIUS. When the externalauthentication server is RADIUS, then the username and password providedwith the login request are encrypted 718 using a RADIUS shared secret.The RADIUS shared secret is typically a shared key. Then, the encryptedvalue is sent 720 to the RADIUS server for authentication. A decision722 then determines whether a response from the RADIUS server has beenreceived. The response, when received, indicates 724 success or failureof the authentication.

On the other hand, when the decision 716 determines that the externalauthentication server is not RADIUS, then a decision 726 determineswhether the external authentication server is LDAP. When the decision726 determines that the external authentication server is LDAP, theusername and password provided with the login request are sent 728 tothe LDAP server for authentication. A decision 730 then determineswhether a response from the LDAP server has been received. The response,when received, indicates 732 success or failure of the authentication.

On the other hand, when the decision 726 determines that the externalauthentication server is not LDAP, a decision 734 determines whether theexternal authentication server is NT domain (NT domain server). When thedecision 734 determines that the external authentication server is NTdomain, a random number is obtained 736 from the NT domain server. Thenthe password provided with the login request is hashed 738 with therandom number. Next, the hashed value is sent 740 to the NT domainserver for authentication. A decision 742 then determines whether aresponse from the NT domain server has been received. The responseindicates 744 success or failure of the authentication.

FIGS. 8A and 8B are flow diagrams of file access request processing 800according to one embodiment of the invention. The file access requestprocessing 800 is, for example, the processing performed when a webbrowsing operation has been requested by a requestor. In other words,the file access request processing 800 can, for example, be theprocessing performed by one embodiment of the block 622 of FIG. 6.

The file access request processing 800 begins with a decision 802 thatdetermines whether a server has been discovered. When the decision 802determines that a server has already been discovered, then a decision804 determines whether the file access request seeks to view foldercontents. When the decision 804 determines that the file access requestdoes desire to view folder contents, then the content of the folder isretrieved 806. The retrieved content is then sent 808 to the requestor.

On the other hand, when the decision 804 determines that the file accessrequest does not seek to view folder contents, a decision 810 determineswhether the file access request is requesting a new folder. When thedecision 810 determines that the file access request is seeking torequest a new folder, then the requestor is prompted 812 for a newfolder name. A decision 813 then determines whether a folder name hasbeen received. When the decision 813 determines that a folder name hasnot yet been received, the file access request processing 800 waits forthe folder name. Once the decision 813 determines that the folder namehas been received, the new folder is created 814.

Alternatively, when the decision 810 determines that the file accessrequest does not desire to create a new folder, then a decision 816determines whether the file access request desires to download a file.When the decision 816 determines that the file access request desires todownload a file, then the requested file is downloaded 818 to therequestor. On the other hand, when the decision 816 determines that thefile access request does not desire to download a file, then a decision820 determines whether the file access request desires to upload a file.When the decision 820 determines that the file access request doesdesire to upload a file, then the requested file is uploaded 822 to therequestor. Alternatively, when the decision 820 determines that the fileaccess request does not desire to upload a file, then additional typesof file access requests could be processed, although none are shown inFIG. 8A. Accordingly, following the decision 820 when the file accessrequest does not desire to upload a file (and no additional types offile access requests are supported), then the file access requestprocessing 800 is complete and ends with no file access operation havingbeen performed. Following the blocks 808, 814, 818 and 822, the fileaccess request processing 800 is also complete and ends but does so withthe requested file access having been performed.

Furthermore, when the decision 802 determines that a server has notalready been discovered, then the file access request processing 800performs the processing shown in FIG. 8B. In this case, a list ofavailable servers is initially discovered 824. Then, a decision 826awaits the selection of one of the available servers by the requestor.Once the decision 826 determines that a server selection has beenreceived, then share information for the selected server is retrieved828. In one embodiment, the share information identifies those of thefolders stored on the selected server that are able to be shared withthird parties, such as remote requestors. A decision 830 then determineswhether the information about the server should be made permanent. Whenthe decision 830 determines that the information about the server shouldbe made permanent, then the server information is saved 832. By savingthe server information, the server is made an “available server” suchthat discovery of the availability of the server is not needed withsubsequent logins to the system. On the other hand, when the decision830 determines that the information about the server should not be madepermanent, then the block 832 is bypassed. In any case, following theblock 830 when the server information is not to be made permanent, aswell as following the block 832 when the server information is to bemade permanent, the processing to discover a server is complete and thusthe file access request processing 800 returns to repeat the decision802 and subsequent operations.

FIGS. 9A-9C are flow diagrams of web resource request processing 900according to one embodiment of the invention. The web resource requestprocessing 900 is, for example, performed by an intermediary server,such as the intermediary server 108 illustrated in FIG. 1A or theintermediary server 158 illustrated in FIG. 1B. The web resource requestprocessing 900 is performed to process a web resource request.

Initially, the host name for the appropriate remote server is obtained902. In one embodiment, the host name can be obtained from storage.Here, the storage can, for example, be the data storage device 214illustrated in FIG. 2A. In another embodiment, the host name can beobtained from the URL associated with the web resource request. Afterthe host name for the appropriate remote server is obtained 902, a hostname lookup is performed 904 to obtain an IP address of the appropriateremote server. A connection is then opened 906 (or maintained if alreadyopened) to the remote server. Next, a secure handshake is performed 908between the intermediary server and the remote server as needed. Any“cookies” associated with the obtained host name are then obtained 910.Following the operation 910, the pre-processing of the web resourcerequest at the intermediary server is complete and the request is nowable to be forwarded to the remote server. At this point, the requestfor the web resource with associated “cookies” is sent 912 to the remoteserver.

A decision 914 then determines whether a response has been received.When the decision 914 determines that a response has not yet beenreceived, the web resource request processing 900 awaits such aresponse. Once the decision 914 determines that a response has beenreceived, then a decision 916 determines whether “cookies” are presentin the response. When the decision 916 determines that “cookies” arepresent in the response, then the “cookies” are extracted 918 from theresponse. The extracted “cookies” are then saved 920. Typically, the“cookies” are stored in central storage provided within the intermediaryserver or other storage associated or coupled to the intermediaryserver. Following the operation 920, as well as following the decision916 when it is determined that “cookies” are not present in theresponse, URLs within headers of the response are modified 922.

A decision 924 then determines whether the response is of a type that isto be modified. Here, in general, a response can be of a variety offorms such as HTML, graphics, pdf, MPEG, or other formats. When thedecision 924 determines that the response is of a type that cannot bemodified (e.g., graphics), then the response can be immediately sent (orforwarded) 926 to the requestor. Then, a decision 928 determines whetherthe response is completed. When the decision 928 determines that theresponse is completed, then the web resource request processing 900returns to repeat the decision 914 and subsequent operations so thatadditional web resource requests can be processed. Alternatively, whenthe decision 928 determines that so far only a portion of the responsehas been sent to the requestor, the web resource request processing 900returns to repeat the decision 914 and subsequent operations or the likeso that subsequent portions of the response can be similarly processed.

On the other hand, when the decision 924 determines that the response isof a type that can be modified (e.g., HTML), then the response isprocessed to modify the response before returning it to the requestor.The processing illustrated in FIG. 9C represents one embodiment ofprocessing that can be performed to modify the response. In particular,a decision 932 determines whether a toolbar is desired. The intermediaryserver can be configured to always, sometimes or never insert thetoolbar. The toolbar can be standardized or customizable by theintermediary server. When the decision 932 determines that a toolbar isdesired, the toolbar HTML is inserted into the response. The toolbarthat is produced by the toolbar HTML can provide controls or contentthat are added to the resulting response so as to facilitate features orfunctionality provided by the intermediary server.

Next, certain URLs within an HTML portion of the response can bemodified 936. In one embodiment, the modifications to the certain URLscan be achieved by modifying the host name portion of URLs withincertain tags of the resulting HTML. In another embodiment, themodifications to the certain URLs can be achieved by adding suffixes tothe certain URLs. The suffixes thus serve to allow the URLs to carryadditional information. Further, certain URLs provided or produced byscripting language portions within the resulting HTML can be modified938. Examples of scripting languages include JavaScript and VBscript. Inone embodiment, a host name portion of the certain URLs provided orproduced by scripting language portions within the resulting HTML aremodified 938. In another embodiment, the certain URLs provided orproduced by scripting language portions are modified 938 to includesuffixes which carry supplemental information. Additional details onmodifying scripting language portions is provided below with referenceto FIGS. 13A and 13B. Thereafter, the modified response is sent 940 tothe requestor.

A decision 942 then determines whether the request has been completed.When the decision 942 determines that the request has been completed,then the web resource request processing 900 is complete and ends. Onthe other hand, when the decision 942 determines that the request is notyet completed, then the web resource request processing 900 returns torepeat the decision 914 and subsequent operations so that remainingportions of the response can be similarly processed upon being received.The web resource request processing 900 can thus operate to process asingle response to a resource request in multiple pieces or blocks ofdata. In such a case, the web resource request processing 900 canprocess a response from a remote server as it arrives so thatresponsiveness to the requestor is not hindered. In this regard, the webresource request processing 900 causes the operations 914-942 to berepeated for each piece or block of data associated with a response.

FIG. 10 illustrates a diagram of an information retrieval system 1000according to one embodiment of the invention. The information retrievalsystem 1000 is generally similar to the information retrieval system 100of FIG. 1A or the information retrieval system 150 of FIG. 1 B. Theoperation of the information retrieval system 1000 is discussed belowwith reference to a representative example which illustrates itsoperation according to one embodiment. The information retrieval system1000 includes a client 1002, an intermediary server 1004 with a datastore 1006, and a remote server 1008. It is assumed that the requestprocessing 300 of FIG. 3 has already been performed and that therequestor is permitted to access the requested resource in the mannersought.

The representative example pertains to a secure request which can beinitiated by the user selecting a hyperlink in a displayed webpage inthe content of a web browsing request. The selected hyperlink is assumedto be

https://secure.danastreet.com/quote/msft:danainfo:host=www.xyz.com

where “https” is the protocol which uses Secure Socket Layer (SSL), issecure.danastreet.com” is the host name with “danastreet.com” being adomain and “secure” being a subdomain, “/quote/msft” being a path to theparticular resource being requested by selection of the hyperlink,“danainfo” is a keyword, and “www.xyz.com” is the host where therequested resource resides. Hence, the domain name lookup of the hostname I&secure.danastreet.com” is resolved to the IP address ofdanastreet.com, which is the intermediary server 1004 for this example.The request is then sent from the client 1002 to the intermediary server1004. The request is, for example, as follows:

GET: /quote/msft:danainfo:host=www.xyz.com HTTP/1.0 Host:secure.danastreet.com Cookie: DSID = 123xyzzbcOther information can also be included within the request such asadditional cookies, encoding-accepted, etc. The cookie is, in thisexample, a session cookie (session identifier) and is used indetermining whether the client 1002 is authorized for use with theintermediary server 1004.

In the case of a secure request, the host name within the request is notable to directly identify the remote server 1008 where the request iseventually to be delivered. However, the host name for the remote server1008 is obtained from information provided with the request. Moreparticularly, the information (i.e., host variable) is provided as asuffix with the request. In this example, the suffix includes theinformation that the host name of the remote server 1008 is“www.xyz.com”. Once the appropriate host name has been obtained, adomain name lookup on the host name (“www.xyz.com”) is performed. Next,a connection from the intermediary server 1004 and the remote server1008 is opened (or maintained if already opened), and secure handshakingis optionally performed. Any cookies in the data store 1006 associatedwith the host name and the requestor can then be obtained. Next, arequest by the intermediary server 1004 is sent to the remote server1008. The request is, for example, as follows:

GET: /quote/msft HTTP/1.0 Host: www.xyz.com Cookie: xyzUserlD = samOther information can also be included within the request. Note that thecookie provided with the original request pertained to the intermediaryserver 1004 and thus is not forwarded with the request to the remoteserver 1008.

The remote server 1008 receives the request and returns a responseheader and some or all of the content of the requested resource. Anexemplary response can have the following format:

HTTP/1.0 200 OK Set-cookie: xyzuserlD = Samual, expires = 01-Jul-2002Content-type: text/html Content-length: 2000 Location:https://www.xyz.com/quote/msft <HTML> ** </HTML>Since the response included a “cookie” to be set, the set-cookie commandis removed from the response and then saved in the data store 1006.Next, to the extent they are present, the URLs within the headers aremodified to point to the intermediary server 1004. In this example, thelocation header includes a full path (including host name), namely,https://www.xyz.com/quote/msft, which is thus modified tohttps://secure.danastreet.com/quote/msft:danainfo:host=www.xyz.com,SSL.In this example, not only are the host names modified but variables arealso added to the end (i.e., suffix) of the URL. The variableinformation added is an indication of the host server having therequested resource and an SSL indicator. With this example, the relativeURLs need to be modified to include the variable information(“danainfo:host=www.xyz.com”) at the end of the relative URLs. The hostnames for the relative URLs are properly provided by the browserapplication operating on the client 1002 which causes the current hostname (“secure.danastreet.com”) to be used for such paths. If desired, atoolbar can be inserted into the HTML data to facilitate operations orfunctions supported by the intermediary server 1004. Still further, theURLs within certain tags within the resulting HTML or those produced byscripting languages are modified to point to the intermediary server1004.

For example, if the HTML data included the following hyperlink:

<a ref=https://www.xyz.com/quote/msft>

then the hyperlink would be modified to the following:

<a ref=https:Hsecure.danastreet.com/quote/msft:danainfo:host=www.xyz.com,SSL>.Also, if the HTML data included the following relative hyperlink:

<a ref=a.html>

then the hyperlink would be modified to the following:

<a ref=a.html:danainfo:host=www.xyz.com,SSL>.

It should be noted that the variable information provided at the end(i.e., suffix) of the URLs need not be at the actual end. Here, suffixis used to generally indicate to the right of the domain name. Indeed,the variable information can be placed in a variety of differentlocations in a URL (even to the left of the domain name). For example,if the original hyperlink itself has variables such as following thecharacters “T” or “#”, then the variable information(“danainfo:host=www.xyz.com”) can, in one example, be placed before thecharacter “?” or “#” indicating the original variables. For example, ifthe HTML data included the following hyperlink:

<a ref=https://www.xyz.com/quote/msft?color=red>

then the hyperlink would be modified to the following:

<a ref=https:Hsecure.danastreet.com /quote/msft:d an ainfo:host=www.xyz.com?color=red>.Also, if the HTML data included the following relative hyperlink:

<a ref=a.html?x=1234>

then the hyperlink would be modified to the following:

<a ref=a.html:danainfo:host=www.xyz.com?x=1234>.

As still another example, if the HTML data included the followingrelative hyperlink:

<a ref=a.html, port=1234>

then the hyperlink would be modified to the following:

<a ref=a.html:danainfo:host=www.xyz.com, port=1234>.

FIG. 11 is a flow diagram of URL modification processing 1100 accordingto one embodiment of the invention. The URL modification processing 1100is, for example, processing performed by operation 936 of FIG. 9C. TheURL modification processing 1100 can, for example, be performed by thecontent transformer 216 illustrated in FIG. 2A or the contenttransformer 278 illustrated in FIG. 2B.

The URL modification processing 1100 begins by selecting 1102 a targetURL within an HTML portion of the response (e.g., webpage). Typically,one or more target URLs are previously identified by scanning the HTMLdata. Then, a decision 1104 determines whether the target URL is arelative URL. A relative URL inherits the characteristics of its sourceURL. The source URL is the URL associated with the webpage (includingthe resulting HTML) that includes the target URL. When the decision 1104determines that the target URL is a relative URL, then the hostnameand/or port suffix from the source URL are appended 1106 to the targetURL.

Alternatively, when the decision 1104 determines that the target URL isnot a relative URL, then a decision 1108 determines whether the targetURL is associated with a secure request (e.g., HTTPS). When the decision1108 determines that the request for the target URL is a secure request,then a secure indicator (e.g., HTTPS) is added 1110 to the target URL.On the other hand, if the decision 1108 determines that the target URLis not associated with a secure request, the operation 1110 is bypassed.

Following the operation 1110 as well as directly following the decision1108 when the target URL is not associated with a secure request, thenthe host name provided with the target URL is added 1112 elsewhere tothe target URL. For example, the host name provided with the target URLcan be appended to the target URL. Then, the original host name providedwith the target URL is replaced 1114 with a predetermined host name. Inother words, the host name originally provided for the target URL iseffectively rewritten such that the original host name is replaced withthe predetermined host name, but the original host name remains part ofthe target URL. For example, the predetermined host name is the hostname for the appropriate intermediary server.

Next, a decision 1116 determines whether a port number is specified inthe target URL. When the decision 1116 determines that a port number isspecified in the target URL, then a port number suffix is added 1118 tothe target URL. The port number originally specified in the target URLfollowing the host name is removed 1120.

Following the operation 1120, the URL modification processing 1100performs a decision 1122. Additionally, when the decision 1116determines that a port number is not specified in the target URL, noport number processing is needed so the decision 1122 is then performed.The decision 1122 determines whether more target URLs are to beprocessed. As previously noted, these target URLs have been previouslyidentified by scanning the resulting HTML data. When the decision 1122determines that there are more target URLs, then the URL modificationprocessing 1100 returns to repeat the operation 1102 and subsequentoperations so that additional target URLs can be processed.Alternatively, when the decision 1122 determines that there are no moretarget URLs, then the URL modification processing 1100 is complete andends.

FIG. 12 is a flow diagram of a script modification processing 1200according to one embodiment of the invention. The script modificationprocessing 1200 is, for example, performed by operation 938 illustratedin FIG. 9C. In general, the script modification processing 1200 operatesto modify script portions within the resulting HTML.

The script modification processing 1200 initially scans 1202 the HTMLdata (e.g., of the resulting HTML) for a <script> tag. A decision 1204then determines whether a script has been found. When the decision 1204determines that a script has not been found, then a decision 1206determines whether there is more HTML data to be scanned. When thedecision 1206 determines that there is more HTML data to be scanned,then the script modification processing 1200 returns to repeat theoperation 1202 and subsequent operations. Alternatively, when thedecision 1206 determines that there is no more HTML data to be scanned,the script modification processing 1200 is complete and ends.

On the other hand, when the decision 1204 determines that a script hasbeen found, then the script is searched 1208 to locate text strings“http://” or “https://” followed by a host name. A decision 1210 thendetermines whether a URL host name has been found by the searching 1208of the script. When the decision 1210 determines that a URL host namehas not been found, then a decision 1212 determines whether the end ofthe script has been reached. When the decision 1212 determines that theend of the script has not yet been reached, then the script modificationprocessing 1200 returns to repeat the operation 1208 and subsequentoperations. Alternatively, when the decision 1212 determines that theend of the script has been reached, then the script modificationprocessing 1200 returns to repeat the operation 1202 and subsequentoperations so that additional scripts can be found and processed.

On the other hand, when the decision 1210 determines that a URL hostname has been found, then a rewritten host name is produced 1214. Thehost name provided within the script is then replaced 1216 with therewritten host name. Following the operation 1216, the scriptmodification processing 1200 returns to repeat the operation 1208 andsubsequent operations so that additional host names within the scriptcan be similarly processed.

FIGS. 13A and 13B are flow diagrams of a script modification processing1300 according to another embodiment of the invention. The scriptmodification processing 1300 is, for example, performed by operation 938illustrated in FIG. 9C. In general, the script modification processing1300 operates to modify script portions within the resulting HTML.

The script modification processing 1300 initially scans 1301 the HTMLdata (e.g., of the resulting HTML) for a <script> tag. A decision 1302then determines whether a script has been found. When the decision 1302determines that a script has been found, then the script is parsed 1304to determine or locate predetermined properties and functions associatedwith the script. A decision 1306 then determines whether at least oneproperty or function has been found in the script. When the decision1306 determines that at least one property or function has been found,then the script modification processing 1300 continues such that thescript is modified with respect to the properties or functions foundwithin the script so that the script operates as intended even thoughthe intermediary server is interposed between client devices and remoteservers.

In particular, for each property or function found within the script,the processing is as follows. A decision 1308 determines whether aselected property or function found within the script pertains to a readof a cookie property. When the decision 1308 determines that theidentified property or function does pertain to a read of a cookieproperty, then the read of the cookie property is replaced 1310 with aget cookies function call. Alternatively, when the decision 1308determines that the identified property or function is not a read of acookie property, as well as following the operation 1310, a decision1312 determines whether the identified property or function pertains toa write to a cookie property. When the decision 1312 determines that theidentified property or function does pertain to a write to a cookieproperty, the write to the cookie property is replaced 1314 with a setcookies functions call.

On the other hand, when the decision 1312 determines that the identifiedproperty or function is not associated with a write to a cookieproperty, as well as following the operation 1314, a decision 1316determines whether the identified property or function pertains to awrite to a property that initiates a request. When the decision 1316determines that the identified property or function does pertain to awrite to a property that initiates a request, then the write to theproperty that initiates (causes) a request is replaced 1318 with a setURL function call. Alternatively, when the decision 1316 determines thatthe identified property or function does not pertain to a write to aproperty that initiates a request, as well as following the operation1318, a decision 1320 determines whether the identified property orfunction pertains to a read from a property that returns a URL. When thedecision 1320 determines that the identified property or function doespertain to a read from a property that returns a URL, then the read froma property that returns a URL is replaced 1322 with an appropriatestring.

Furthermore, following the decision 1320 when the identified property orfunction does not pertain to a read from a property that returns a URL,as well as following the operation 1322, a decision 1324 determineswhether more properties or functions were found in the script that stillneed to be processed. When additional properties or functions have beenfound and need processing, the script modification processing 1300returns to repeat the decision 1308 and subsequent operations so thatthe additional properties or functions can be similarly processed. Onthe other hand, when the decision 1324 determines that all theproperties or functions that have been found within the script have beenprocessed, then the script modification processing 1300 performs adecision 1326. The decision 1326 is also performed when the decision1302 determines that a script has not been found. The decision 1326determines whether there is more HTML data to be scanned. When thedecision 1326 determines that there is more HTML data to be scanned,then the script modification processing 1300 returns to repeat theoperation 1301 and subsequent operations. Alternatively, when thedecision 1326 determines that there is no more HTML data to be scanned,the script modification processing 1300 is complete and ends.

Representative examples of a get cookies function, a set cookiesfunction, a set URL function, and string substitution are providedbelow. These examples are provided to assist understanding and thusshould not be deemed restrictions on any aspect of the invention. Thefollowing examples use JavaScript as the scripting language.

A first example with respect to the get cookies function and operation1310 is as follows. In this example, the script includes a scriptinstruction

var c=document.cookie;

which assigns the cookies associated with the document (page) to thevariable c. This script instruction would be replaced with

var c=get cookies (“othercookie=abc”);

which assigns the cookies present on the intermediary server for theparticular domain of the document (page) and the particular user (e.g.,“othercookie=abc”). In addition, the get cookies function takes thecookies from the intermediary server as its argument and adds to itother cookies that are set by the script.

A second example with respect to the set cookies function and operation1314 is as follows. In this example, the script includes a scriptinstruction

document.cookie=“selection=ijk; expires= . . . ”;

which stores the cookies associated with the document (page) in thebrowser. This script instruction (statement) is replaced with

document.cookie=set cookie (“<domain>”, “selection=ijk; expires= . . .”);

which stores the cookies associated with the document (page) in thebrowser and also to the intermediary server. The set cookie functionincludes two arguments. The first argument identifies the domain of thepage having the script. The second argument is the value that wasoriginally being assigned to the document.cookie property. The setcookie function combines these two arguments and sets a cookie calledservercookieX with no expiration, where X represents a distinguishingnumeric value. The browser will cause this cookie to be sent to theintermediary server. The intermediary server can then incorporate thecookie into the cookie storage for the user. The cookie can also be usedto expire an existing cookie in storage for the user. Once the cookie isstored at the intermediary server, the next page that the intermediaryserver returns will cause the servercookieX to expire because it is nolonger needed. Any calls to the set cookie function will also append anycookie values provided within the servercookieX

To further illustrate, consider the following example where a page fromwww.xyz.com has the following script:

document.cookie = “a=b”; var x = document.cookie;.Assume also the www.xyz.com server has previously returned a cookie tothe intermediary server that has a name “id1” with a value “sam”. Thecode above will be transformed into:

document.cookie = set cookie (“www.xyz.com”, “a=b”); var x = get cookie(“id 1=sam”);.The first line will cause a cookie “servercookie0” to be set that hasthe value “a=b−domain=www.xyz.com”, hence the whole cookie will be:

servercookie0=a=b−domain=www.xyz.com.

Note that the domain part of the servercookie0 is used purely by theintermediary server so that it knows which domain is setting the cookie.The second line calls the get cookies function which takes its firstargument (filled in by the intermediary server while the script wasrewritten) and examines all servercookie0's cookies at the browser. Itconcatenates the first argument together with any servercookieX cookies,and returns the result:

id 1=sam; a=b.

Note, this is the same result that would have been returned from theoriginal page had it not been rewritten.

A third example with respect to the set URL function and operation 1318is as follows. The set_URL function operates to modify properties thatcause a request. In this example, the script includes a scriptinstruction

document.location=“http://www.xyz.com/foo.htmi”;

which directs the browser to a new page. Such a script instruction canbe replaced with

document. location = set URL “”, “http://www.xyz.com/foo.html”);.The set_URL function call takes two arguments. The first argument isfilled in by the intermediary server while the script is being rewrittenand contains any parameters that would normally be provided in a suffix(e.g., “danainfo:”) to follow a URL. It is not always needed, as will beexplained below. The second argument is the URL, though it couldactually be a script expression (e.g., function call) that assembles orreturns a URL.

The set URL function examines the URL being set and rewrites it to be ofa form that will direct the browser to the intermediary server. As notedabove, the modification to URLs can be achieved with various techniques.

If the page is using the host name modification technique, then relativeURLs do not need to be modified since the host name encodes thenecessary information. If the URL is a full URL, then the set URLfunction has all of the information it needs to convert the URL. Forexample, a suffix (e.g., “:danaInfo:host=xxx”) can be appended to theURL. Thus, if the page that the script appears on is using the host namemodification technique, the first argument is not needed by the set URLfunction.

Alternatively, if the page upon which the script is present is using theURL suffix technique, then a relative URL that is passed to the set URLfunction needs to have the same suffix applied to it. In this case, theintermediary server will insert, as the first argument to the set URLfunction, any arguments that need to be passed in the suffix. Forexample, if the URL of the page is:

https://secure.danastreet.com/quote/msft:danaInfo:host=www.xyz.com

and a script instruction on the page includes:

document.location=“/quote/ibm”;

then the rewritten script instruction would look like:

document.location=set URL(“Host=www.xyz.com”, “/quote/ibm”);

and the returned result from the set URL function would be:

/quote/ibm:danaInfo:host=www.xyz.com

which would result in a request from the browser for:

https://secure.danastreet.com/quote/ibm:danaInfo:host=www.xyz.com.

Alternatively, if the script instruction were instead:

document.location=“https://www.abc.com/info/msft”;

then the rewritten script instruction would look like:

document.location = set URL(“Host=www.xyz.com”,“https://www.abc.com/info/msft”);and the returned result from the set URL function would be:

https://secure.danastreet.com/info/msft:danaInfo:host=www.abc.com.

Note that, in this case, the first argument to the set URL function isnot needed because the second argument is a full URL and contains all ofthe information necessary to construct the final URL.

It should be noted that there are many functions or properties that,when written to, can cause the browser to fetch a URL. Some examplesinclude:

window. open (‘url’, ...) form.action =‘url’; document.location =‘url’;document. location. replace(‘url’); image.src =‘url’;.

A fourth example with respect to the string substitution and operation1322 is as follows. The string substitution operates to modifyproperties that return a URL. Here, script instructions that read from aproperty that return a URL are replaced with a constant string. In thisexample, if the script includes

var url=document.location;

such would be replaced by:

var url=“http://www.yahoo.com/foo.htmi”;

This operation serves to ensure that any script examining itsenvironment would not be confused by the fact that the actual URL of thepage is different from what it expects. Note that there is more than oneproperty that may need to be modified. Some examples of properties thatcan be so modified include:

document. location (returns full URL) document.domain (returns just thehostname part of URL).

FIG. 14 is a flow diagram of email request processing 1400 according toone embodiment of the invention. The email request processing 1400 is,for example, suitable for use as the email request processing performedat block 628 of FIG. 6.

The email request processing 1400 initially accepts 1402 a secureconnection with a mail client. Here, the secure connection between themail client and the intermediary server that is being accepted 1402 can,for example, be made secure through use of a Secure Socket Layer (SSL).Next, the requestor is prompted 1404 for authentication. Typically, therequestor is prompted 1404 to enter at least a password that can be usedto authenticate the requestor. A decision 1406 then determines whether apassword has been received. Typically, but not necessarily, the passwordbeing received is encoded in some manner. For example, base-64 encodingis often utilized. When the decision 1406 determines that a password hasbeen received, then the password can be separated 1408 into a mailserver password and an authentication server password. As an example,the received password can include both the mail server password and theauthentication server password separated by a password separator.

Next, the email server attempts to verify 1410 the mail server password.At about the same time, the authentication server password can attemptto be verified 1412 with the authentication server. Next, a decision1414 determines whether both of the verifications of blocks 1410 and1412 have been successful. When the decision 1414 determines that bothof the verifications have been successful, then a hashed version of thepassword is stored 1416. Then, the mail operation processing 1418associated with the email request is performed. On the other hand, whenthe decision 1414 determines that both of the verifications of blocks1410 and 1412 are not successful, then the email request is denied 1420.Following the operations 1418 and 1420, the email request processing1400 is complete and ends.

FIG. 15 is a flow diagram of mail operation processing 1500 according toone embodiment of the invention. The mail operation processing 1500 is,for example, one example of processing that can be performed by theblock 1418 illustrated in FIG. 14.

The mail operation processing 1500 begins with a decision 1502 thatdetermines whether the connection has timed-out or closed. Here, theconnection refers to the secure connection between the mail client andthe intermediary server. When the decision 1502 determines that a secureconnection has timed-out or closed, then email access to the mail serveris denied 1504. Hence, following the block 1504, the mail operationprocessing is complete and ends when the secure connection has timed-outor closed. However, the processing could continue to return a login pageto the requestor to force the requestor to login and be authenticated inorder to gain access to the mail server.

On the other hand, when the decision 1502 determines that an existingconnection has not timed-out or closed, then a decision 1506 determineswhether a command from a mail client has been received. When thedecision 1506 determines that a command from a mail client has not beenreceived, then the mail operation processing 1500 returns to repeat thedecision 1502 and subsequent operations until a command from the mailclient has been received or until the connection has timed-out orotherwise closed.

Once the decision 1506 determines that a command from a mail client hasbeen received, then the command is forwarded 1508 to the mail server.Next, a decision 1510 determines whether a response has been receivedfrom the mail server. When the decision 1510 determines that a responsehas not yet been received from the mail server, then the mail operationprocessing 1500 awaits such a response. Once the decision 1510determines that a response has been received, then certain UniversalResource Locators (URLs) within the response are modified 1512. Forexample, as part of the content transformation, links or URLs are ableto be modified to redirect the links through the intermediary server.Next, the response is sent 1514 to the mail client. Here, the responseis sent to the mail client using the connection that exists between themail client and the intermediary server. Following the block 1514, themail operation processing 1500 returns to repeat the decision 1502 andsubsequent operations so that additional commands can be processed withrespect to the mail server.

FIG. 16 is a flow diagram of authentication processing 1600 according toone embodiment of the invention. The authentication processing 1600represents one embodiment of the block 1412 illustrated in FIG. 14. Inthis embodiment, the intermediary server is able to bypass or avoidactual verification of a password with the authentication server whencertain conditions are met. By doing so, the authentication can, in manycases, be performed very quickly and without the need to burden or annoyrequestors.

The authentication processing 1600 begins with a decision 1602 thatdetermines whether a stored hashed password is available. When a hashedpassword is previously stored (operation 1416 of FIG. 14), the hashedpassword can later be retrieved and used in this regard. Hence, when thedecision 1602 determines that the stored hashed password is available,then the stored hashed password, a time last authorized and a time lastused password are retrieved 1604. Typically, these values are stored inthe data store associated with the intermediary server and are storedvalues that are particular to the requestor.

Next, a decision 1606 determines whether a hash of the received passwordequals the stored hashed password. When the decision 1606 determinesthat the hash of the received password is equal to the stored hashedpassword, then the requestor is, in effect, authenticated, becauseearlier in the session they entered the proper password that was thenauthenticated. Further, a decision 1610 determines whether the timesince the time last authorized is greater than a maximum sessionduration. Here, the variable indicating the duration of time that hasexpired since the time last authorized is compared to the maximumsession duration. Typically, the maximum session duration is set by therequestor or by the system administrator of the intermediary server.

In any case, when the decision 1610 determines that the time since thetime last authorized does not exceed the maximum session duration, thena decision 1612 determines whether the time since the time last usedpassword exceeds a maximum idle time. Here, the variable indicating theduration of time that has expired since the time last used password iscompared to the maximum idle time. When the decision 1612 determinesthat the time since last used the password does not exceed the maximumidle time, then authentication 1614 by the authentication server isdeemed successful without having to interact with the authenticationserver. Hence the authentication with respect to the authorizationserver is able to be bypassed when the hash of the received passwordequals the stored hash password, provided the time since last authorizeddoes not exceed the maximum session duration, and further provided thetime since last used the password does not exceed the maximum idle time.

On the other hand, the password is verified 1608 with the authenticationserver when the special conditions do not exist. For example, when thedecision 1602 determines that the stored hash password is not available,then the verification 1608 with the authentication server is performed.Likewise, when the decision 1606 determines that the hash of thereceived password is not equal to the stored hash password, then theverification 1608 of the password with the authentication server alsoneeds to be performed. Still further, when the decision 1610 determinesthat the time since last authorized exceeds the maximum session durationor when the decision 1612 determines that the time since last used thepassword exceeds the maximum idle time, then the password needs to beverified 1608 with the authentication server.

Following the operations 1608 and 1614, the authentication processing1600 returns to perform other processing, namely, returns to theoperation 1414 illustrated in FIG. 14. Hence, when the verification 1608is able to be bypassed because the above-mentioned special conditionsexist, the authorization processing is greatly simplified and oftenavoids the need to perform complicated authentication processing withrespect to an authentication server or to prompt a requestor forauthentication information.

FIGS. 17A and 1713 illustrate an example of a computer system that maybe used in accordance with some embodiments of the invention. Thecomputer system can, for example, correspond to any of the clientmachines, the intermediary server, or the remote or private servers.FIG. 17A shows a computer system 1721 that includes a display 1723,screen 1725, cabinet 1727, keyboard 1729, and mouse 1731. Mouse 1731 mayhave one or more buttons for interacting with a graphical userinterface. The cabinet 1727 houses a removable medium (e.g., CD-ROM)drive 1733, system memory and a hard drive (see FIG. 1713) which may beutilized to store and retrieve software programs incorporating computercode that implements some embodiments of the invention, data for usewith some embodiments of the invention, and the like. Although CD-ROM1735 is shown as an exemplary computer readable storage medium, othercomputer readable storage media including floppy disk, tape, DVD, flashmemory, system memory, and hard drive may be utilized. Additionally, adata signal embodied in a carrier wave (e.g., in a network including theInternet) may be the computer readable storage medium. In oneimplementation, an operating system for the computer system 1721 isprovided in the system memory, the hard drive, the CD-ROM 1735 or othercomputer readable storage medium and serves to incorporate the computercode that implements some embodiments of the invention.

FIG. 1713 shows a system block diagram of the computer system 1721 usedto perform the processing of an embodiment of the invention. As in FIG.17A, the computer system 1721 includes monitor 1723, keyboard 1729, andmouse 1731. The computer system 1721 further includes subsystems such asa central processor 1751, system memory 1753, fixed storage 1755 (e.g.,hard drive), removable storage 1757 (e.g., compact disk), displayadapter 1759, sound card 1761, speakers 1763, and network interface1765. The central processor 1751 can, for example, execute computerprogram code (e.g., an operating system) to implement some embodimentsof the invention. An operating system is normally, but necessarily,resident in the system memory 1753 during its execution. Other computersystems suitable for use with some embodiments of the invention mayinclude additional or fewer subsystems. For example, another computersystem could include more than one processor 1751 (i.e., amulti-processor system) or a cache memory.

The system bus architecture of computer system 1721 is represented byarrows 1767. However, these arrows are illustrative of anyinterconnection scheme serving to link the subsystems. For example, alocal bus could be utilized to connect the central processor to thesystem memory and display adapter. The computer system 1721 shown inFIG. 17A is but an example of a computer system suitable for use withsome embodiments of the invention. Other computer architectures havingdifferent configurations of subsystems may also be utilized.

Although the described embodiments refer to the use of a singleintermediary server within an information retrieval system, it should berecognized that the information retrieval system can also include aplurality of intermediary servers. The various intermediary servers canindividually receive requests from client machines and forward them tothe appropriate servers and return responses back through theintermediary server to the client machine. By having multiple servers,not only can additional processing power be obtained, but loadbalancing, fault tolerance and localization issues can also beaddressed.

FIG. 18 is a block diagram of some embodiments. Some embodiments includeat least a client-side portion, some embodiments include at least aserver-side portion, and some embodiments include at least one of each.FIG. 18 shows a client network 1810 which in this example includes aclient machine, a remote network 1840 which in this example includesenterprise servers, and the Internet 1890 coupling the client network1810 and the remote network 1840. The client machine includes 1810includes a client application 1812 of client-server applications, suchas a Win32 application; a layered service provider (LSP) 1814; anamespace provider (NSP) 1815; a session manager 1816; and a Winsock API1818. The remote network 1840 includes server applications 1842 ofclient-server applications; DNS server 1844, and intermediate server1846. The intermediate server 1846 includes a daemon 1848. The sessionmanager 1816 and the daemon 1848 communicate over the Internet 1890 viaa communication protocol 1850 (e.g., over port 443). The session manager1816 can be called a communication protocol client. In many embodimentsthe intermediate server can be considered part of the remote network.

Some embodiments are called the secure application manager. Someembodiments of the secure application manager have separation at anetwork level between the client and the enterprise resources, and aretherefore more secure.

Some embodiments of the secure application manager include clientsoftware, e.g. Win32 based software; that can transparently redirectremote access secure network connections on a per-application and/or perhost basis securely through an intermediate server to enterpriseclient/server application resources. An administrator, for example, ofthe intermediate server, can configure some embodiments to secure someor all access into enterprise resources from specified clientapplications. Some examples of client-side applications are e-mailapplications, contact management applications, or date book applicationssuch as Outlook; client-side enterprise resource planning applicationssuch as SAP R/3 client, client-side application service software such asCitrix ICA, browsers such as Internet Explorer, etc.

Some embodiments redirect the network connection request within aWindows socket layer, which can include one or more of: a Winsockdynamic link library, a Winsock 2 dynamic link library, an applicationprogramming interface, a layered service provider (LSP), a serviceprovider interface for the layered service provider, a namespaceprovider (NSP), a namespace provider interface, a transport serviceprovider interface, and the transport service provider.

FIG. 19 shows an embodiment including Winsock applications and a Windowssocket layer. FIG. 19 shows Winsock applications 1910, a Winsock API1915, a Winsock DLL 1920, a Winsock transport SPI and namespace SPI1930, an LSP SPI 1935, LSP 1936 and 1938, transport service providers1945 (TCP/IP transport service provider and IPX/SPX transport serviceprovider shown), and namespace providers 1955 (DNS namespace providerand IPX namespace provider shown).

FIG. 20 shows another embodiment including Winsock applications and aWindows socket layer. FIG. 20 shows Winsock 2 applications 2010, aWinsock 2 API 2015, a Winsock 2 DLL 2020, a Winsock 2 transport SPI2030, a Winsock 2 namespace SPI 2040, transport service providers 2050,and namespace providers 2060.

The client software can be downloaded and launched (e.g., from anActive-X control that can exist on the intermediate server). The LSP andNSP can be installed into the system. The secure application managerproxy can be downloaded and launched (e.g., by the Active-X control).

In the early 1990s several software vendors collaborated and brought thefirst standardized TCP/IP connectivity to Windows, well known asWinsock. With the success of this software vendors found manyapplications for hooking into the network traffic stream and beginhooking, chaining, and replacing Winsock DLLs. This provided a solutionfor monitoring, modifying, or redirecting network traffic. However, thelack of a standard way to do this created many compatibility issues onWindows platforms.

In the mid 1990s the Winsock forum created the Winsock-2 specification.Some of the goals of this new API were: support for more Win32 I/Omechanisms such as overlapped and event based I/O, protocol Independenceso that multiple vendors could plug in any type of network protocol tothe Winsock API, and to standardize the mechanism for hooking Winsockcalls (LSP).

Microsoft shipped the first Winsock-2 enabled OS in 1996 with Windows NT4.0 and later with the release of Windows 98, released a Windows 95update to upgrade the older systems to Winsock2.

The initial Winsock-2 and vendor LSP implementations were buggy andproducts based on these had limited success. Today in 2003 the Winsock-2framework has stabilized and several products based on LSPs have proventhe technology.

Winsock-2 standardizes not only the application programming interface(API) but the service provider interface (SPI) for both transport andnamespace providers. In addition, the framework supports layering oftransport providers, aka. LSPs. The actual Winsock DLL is implemented byMicrosoft and any vendor is free to implement transport and namespaceproviders and install them into the system. Applications written to thelegacy Winsock-1 API (e.g., winsock.dll, wsock32.dII, both known as aWinsock dynamic link library) are thunked to the new Winsock-2 API (ws232.dII, also called a Winsock dynamic link library).

A layered service provider (LSP) can be used in Windows, which providesLSP architecture that allows applications to roll out custom transportservices over TCP/IP stack. If there is a LSP service installed on aclient machine, then Win32 applications running on the client machinecan automatically load the LSP service. The LSP service can thenintercept some or all calls to Winsock calls and can add additionalcustom transport mechanisms. It can inspect, modify, and/or redirectnetwork data and/or events from the Winsock API. By capturing networktraffic at this level, the LSP can live in the context of the callingapplication and can have full access to its process information. Theremay be access application level data and not to TCP and/or IP levelheader information.

The LSP service can intercept traffic, such as some or all socketconnect calls coming from a configured list of applications (forexample, at the intermediate server), and securely transmit, such asover HTTPS using a communication protocol, for example a custom orstandard protocol, through a session manager. Similarly, the NSP canhandle DNS queries for a destination host name coming from a configuredlist of applications (for example, at the intermediate server), andsecurely transmit, such as over HTTPS using a communication protocol,for example a custom or standard protocol, through a session manager.

For handling session timeouts and/or simultaneously handling otheraccess mechanisms, the LSP service can automatically choose to ignore(directly pass it to the Winsock API) the traffic intended for the host,which can be an IP address of the host where a client-side portion wasdownloaded from, which can be even when a browser is configured to be anapplication to be secured via the secure application manager.

Some embodiments include a dynamic link library such as a Win32 DLL thatcan export a function, WSPStartup( ). The installer can register the LSPand one or more protocol chains that describe the protocols to layerover and the order with respect to other LSPs. When an application loadsthe Winsock library, Winsock can call the LSP's WSPStartup( ) function.At this time, the LSP can return its SPI entry points to the Winsockcatalog or the LSP positioned above in the chain. The LSP can load thenext provider in the chain and perform the same entry point exchange.The chain can end at the transport service provider called the basetransport provider. At this point, the calls can be dispatched to andfrom a TDI protocol driver in the kernel.

The LSP can be based on reference implementations supplied by Microsoft.

The LSP protocol chain install/uninstall code can be implemented in thesame DLL using the self registering functions DIIRegisterServer( ) andDIIUnregisterServer( ) for easy integration into installers. Otherembodiments can be implemented in multiple DLLs.

A namespace provider (NSP) can perform name resolution for a given namespace. For the TCP/IP namespace the Microsoft implementation can performDNS resolution. An NSP can include a dynamic link library such as aWin32 DLL that exports a function, NSPStartup( ). Similar to an LSP, theinstaller can register the NSP. Winsock can load the NSP as needed andexchange entry points. When NSPs are layered, e.g. multiple NSPs areinstalled sharing the same namespace, the behavior is undefined inWinsock-2.

The NSP can intercept DNS lookups to relay DNS requests to the secureremote network. The LSP can intercept the Winsock connect( ) call toredirect some or all outgoing TCP connections to the secure applicationmanager proxy. The secure application manager can have multiple modes ofoperation. In one mode, such as an application proxy mode, the LSP loadsinto an administrator selected set of applications and redirects some orall connections within those applications to the intermediate server. Inanother mode, such as a destination proxy mode, the LSP loads into someor all processes and redirects based on an administrator selected listof destination hosts, address, and/or ports.

The NSP can be installed and co-exist with the Microsoft DNS provider.The secure application manager NSP can securely relay DNS requestsacross to the remote network. The Microsoft Winsock-2 implementationcalls each provider in the order that they are enumerated in theregistry. The first provider to return a non-empty result in a queryends the cycle and considers that to be the valid response. The NSP canbe installed in the specified way using the Winsock-2 configuration APIand can be re-ordered in the registry by swapping the names of theenumerated keys in the registry.

Microsoft can change the way this behaves. Another embodiment parses andspoofs DNS requests. However, parsing and spoofing the raw DNS trafficfrom the LSP adds difficulty to tracking which application is issuingthe DNS request and impairs the ability to perform hostname lookups on aper-application basis.

The NSP entry points can be implemented in the same DLL as the LSP tokeep the installation simple and lightweight. Other embodimentsimplement multiple DLLs.

The NSP install/uninstall code can be implemented in the same DLL usingthe self registering functions DIIRegisterServer( ) andDIIUnregisterServer( ) for easy integration into installers. Otherembodiments implement multiple DLLs.

The secure application manager proxy can be a window-less Win32application that can perform one or more of the following operations:manage connection to intermediate server, performs DNS requests for theNSP, manages port mapping for the LSP, retrieve secure applicationmanager configuration data from intermediate server, and maintainredirect table.

A session manager (communication protocol client) can be, for example, aclient such as a Win32 client (in some cases, ActiveX based) that canaccept some or all traffic from the LSP service and/or can forward thetraffic to the intermediate server using the communication protocol. Thesession manager listens on, for example, loopback addresses (127.0.0.1,127.0.0.2. etc) for one, some, or all destination hosts secured via theLSP service.

The session manager can run in the system tray and can display a list ofsecured applications on the client applications. For each activeapplication, the session manager can also display the status of thesession, such as the number of bytes sent/received, similar to analready existing session manager.

The communication protocol can simulate TCP socket connections usingHTTPS sessions. Each socket connection can be simulated using twohalf-duplex HTTPS sessions (upstream and downstream). The communicationprotocol can allow the session manager to secure some or all the trafficoriginating from client/server applications over SSL. By transmittingover HTTPS, the communication protocol can work through proxies andfirewalls.

A single worker thread (in other embodiments, multiple threads orprocesses) can handle these tasks while a separate request thread (inother embodiments, the same thread or a different process) can handleincoming requests from the LSP and/or NSP. The request thread canminimize response times, avoiding unnecessary blocking in the clientapplication that made the request. Some or all tasks performed by theworker thread can be asynchronous, making one thread for all taskssufficient. If any performance issues arise due to a single threadprocessing the tasks, some tasks can be offloaded, such as to differentworker threads.

The secure application manager can be launched from, for example, anActive-X control embedded in a web page on the intermediate server. TheSSL session authentication can be handled by a browser such as InternetExplorer. When the secure application manager proxy is launched, it canattempt to establish a connection to the intermediate server. It canaccomplish this with a name of the intermediate server host and thecurrent session cookie. The Active-X control can write the host andcookie to a shared memory region using memory mapped files with, forexample, the following names for the memory and mutex:

<name>:<communication protocol>:Pagelnformation:SharedMemory<name>:<communication protocol>:Pagelnformation:Mutex

When this shared memory region is acquired, the data stored at thelocation is in a format, such as:

Data Format: <session cookie>+‘\0’+<ivehostname>‘\0’

Data parameters can be passed into the communication protocol API forestablishing a communication protocol session. In the event that thesession times out, the communication protocol API can notify the secureapplication manager proxy which can query the user if the user wishes tore-connect or exit secure application manager, for example, via a pop upof a modal dialog box. If the user chooses to reconnect, the secureapplication manager proxy can open a new window, such as an InternetExplorer window, to the secure application manager page, which can forcethe login and re-launch of another instance of the secure applicationmanager proxy. The new instance of the proxy can detect a previousinstance and signal it, telling it to re-connect to the intermediateserver. The new instance can exit after signaling the previous instance.

With an intermediate server session established, the secure applicationmanager proxy can download the configuration data with a newcommunication protocol command. The data can come down to the secureapplication manager proxy in a form such as name=value pairs separate bya ‘;’. An example configuration string might look like:

“opmode=0;exitmode=0;apps=outlook,exe|Microsoft Outlook|28cb48bd8f,telnet.exe, netscp*; dests=10.10.3.0/8”

If the secure application manager can be configured to run indestination proxy mode, IP address/mask/port combinations can be placedinto the redirect table for static redirects. Host names can be placedin a separate list and at run-time, the DNS lookup result can be placedinto the redirect table for the purpose of redirecting based on theaddress associated with that hostname, and/or passing the hostnameassociated with the IP address to the communication protocol connectioncall.

The worker thread can receive DNS requests from the shared memory queueand pass the requests to the intermediate server. When the resultarrives, it can be returned to the LSP response queue specified in therequest. If the intermediate server fails to resolve the hostname, anempty result can be returned from the NSP which can allow the MicrosoftDNS provider to perform the lookup.

A portmap request arrives from the LSP before it initiates theconnection. The secure application manager proxy can find an availablelocal address and port, such as a loopback address and port, to bind toand returns both back to the LSP while recording the association. TheLSP then can initiate a connection to this loopback address and port.When the secure application manager proxy receives a connectionindication it can initiate a connection to the intermediate server. Whenthis connection is successfully made, the incoming connection from theloopback address can be accepted. Once the connections are made, a statemachine based on, for example, the asynchronous 10 characteristics ofthe Winsock API and/or communication protocol API can handle the portmapped data.

The secure application manager can use a range of loopback addresses forport mapping, starting at 127.1.0.1 and ending at 127.1.255.254. Thereare many ways to choose a loopback address. In one embodiment, thesecure application manager can first attempt to bind the startingaddress 127.1.0.1 and destination port. If this address is already inuse, it can attempt to bind to the next address, 127.1.0.2. This cancontinue until it finds an available address to bind to. In the eventthat all 65 k addresses are in use on a given port, it can start over at127.1.0.1 attempting to bind to alternate port numbers.

The user interface can be built as a separate Win32. This implementationcan be broken out from the secure application manager proxy to free theuser interface implementation from the constraints of the window-lesssecure application manager proxy. The Microsoft Foundation Classes canimplement the user interface. It can launch as a hidden application witha system tray Icon. A selection (e.g., a right click of the icon) canpull up a menu. The user interface can be opened with a selection (e.g.,double click on the icon, selecting open from the right hand clickmenu).

To give users a sense of which applications are and are not secured, aDLL, such as a separate DLL, can use Win32 status hooks to intercept theWM PAINT message for each process. The hook can provide a visual cue,such as by writing a status icon, e.g. to the upper right hand side ofeach window, to indicate if the application is securely connected to theintermediate server or not. The state information can come from readinga shared memory region created by the secure application manager proxy.

The LSP can be properly installed into the system to deal with lockedfiles, versioning, and/or uninstallation.

The Active-X control can run within the browser which can be served upfrom the intermediate server server. The control can download,uncompress, and/or run the programs and/or installations associated withsecure application manager. It can be used with the network connect andsecure application manager. The applications it launches can bescriptable; for example, VBscript can pass the program names to thecontrol for download, uncompress, and/or launch.

The intermediate server daemon processes some or all the trafficreceived from the session manager. The daemon can in turn make socketconnections to the destination hosts in the enterprise and cansends/receive data on behalf of the client application. The daemon canalso contact the DNS server for the initial hostname resolution for theLSP/session manager running on the client.

The intermediate server secure application manager can have one or morefunctions.

1. All TCP based client/server applications can be supported, such asones that do not contain server-initiated connections.

2. Some embodiments can support applications such as Outlook, LotusNotes, and/or NetBIOS proxying (access to windows mapped networkdrives).

3. Some embodiments can be supported on Windows platforms and browserssuch as Internet Explorer.

4. Some embodiments can work in all Internet access modes such asdialup, broadband and/or LAN scenarios from the client machine.

5. Some embodiments can work through client-side proxies and firewalls,such as devices that allow SSL traffic over port 443.

6. Some embodiments support third party end point security products.Some embodiments with application level access can be used from a secureclient machine. Some embodiments work with personal firewalls such asWhole Security, Sygate, etc. before launching a network level accesssession.

The intermediate server can support integration with “Whole Security”vendor in the initial release. Specified registry settings can bechecked on the client machine to make sure that some processes arerunning before launching the session.

Here is an example for supporting the “Whole Security”/ZoneAlarmintegration:

-   -   1. Network client checks for the existing of the registry key

HKEY_LOCAL_MACHINE\SOFTWARE\Zone Labs or HKEY_CURRENT USER\Software\ZoneLabs

-   -   2. Network client then checks for a running process that is tied        to the ZoneAlarm exe.

Some embodiments implement integration generically enough such that anadministrator can specify the vendor name and the associated registrykeys/process name, and be supported by the secure application managerclient.

One or more of the following can be administrator requirements.

1. The secure application manager can be a group-level feature. Theadministrator can restrict the users that will have access to the secureapplication manager, such as with intermediate server group basedpolicies.

2. The administrator can configure the secure application managerfeature in a mode such as application level access, access only tospecified destination hosts, and/or access to specified destinationhosts and ports.

-   -   2.A. For application level access, the administrator can specify        a list of applications that need to be secured, e.g., sapR3.exe,        outlook.exe, ie.exe, etc. NetBIOS proxying can be treated as a        special application, such as with a keyword “netbios”.

For one or more applications, an administrator can specify one or moreof the following path of the executable (e.g., a complete path for theexecutable such as “%system Root\Program Files\SAP\sap r3.exe”, afriendly description (e.g., SAP R/3 client, and/or a default of theexecutable name), an optional list of MD5 checksum values for theapplication executable that can be enforced by the secure applicationmanager LSP for security reasons, and an optional list of destinationhosts/ports that can be secured from the client applications.

-   -   2.B. For access only to the specified destination hosts, an        administrator can specify a list of destination hosts that need        to be secured. A secure application manager can automatically        secure some or all the traffic intended for these destination        hosts on some or all the TCP ports, UDP ports, and/or        application version number.

A destination host could be represented as one or more of: a single IPaddress or IP address range; a destination hostname or a list of hostnames. Host names can use wildcard expressions such as * and ?, where *represents a pattern for any number of characters and ? represents apattern for a single character. If IP addresses are specified and thereis a reference from an application to a hostname, then the secureapplication manager can check the IP address to the list of hosts in theIF address range. The secure application manager can support at leastone-way DNS lookup support for hostnames.

The destination host can be a hostname or an IP address. For hostnames,wildcards can be supported. The destination host can specified with amask to represent a subnet in the format 10.10.0.0/255.255.0.0

-   -   2.C. For access to specified destination hosts and ports, an        administrator can specify the list of destinations hosts and the        ports that need to be secured. The secure application manager        can automatically secure the traffic intended for these        destination hosts and the ports.

3. The administrator can choose to provide access to other intermediateserver functionality such as web browsing, file, telnet/ssh etc for thesame group. The secure application manager can be configured as anadditional access mechanism for a sub-group.

4. The administrator can configure the secure application manager for agroup. The configuration of Java versus secure application manager(e.g., ActiveX) version can be automatically performed based on theclient operating system (e.g., non-windows vs. Windows) by looking inthe user-agent string.

5. In some embodiments, the administrator can configure an “auto-launch”secure application manager client for the end users (such as sessionmanager).

6. The administrator can select “automatic full clean-up (uninstall) ofthe secure application manager client” on, for example, a per-groupbasis. A default value for this can be “disabled” which can provide anoption for the end user to uninstall all the components on the secureapplication manager session manager.

7. The administrator can specify integration with an end-point securityproduct such as “whole security”. When selected, the secure applicationmanager client can first check for the existence of the specifiedsoftware package and make sure it is running before launching the secureapplication manager session. If a user's machine does not have thespecified software or it is not running, then user can be returned anerror with a proper description without launching the session.

For the purpose of making DNS and/or portmap requests from each instanceof the LSP to the secure application manager proxy, some form ofinterprocess communication can be necessary. Windows has manyinterprocess communication types with dependencies. Interprocesscommunication which depends on the network can cause a re-entry into theLSP and create infinite loops. Interprocess communication which dependson Windows messages can be prone to errors and deadlocks from within anLSP with little control over the thread and process it is running in.Remaining choices are not implemented across many Microsoft platforms.

As an interprocess communication mechanism, memory mapped files can haveno dependencies, exist across many platforms, and be relativelyefficient.

To perform a synchronous call across processes from the LSP to thesecure application manager proxy, multiple queues (e.g., two queues) anda Win32 Named Mutex can be used. The message queue can be implementedover a contiguous block of memory (memory mapped file) and can supportvariable sized messages. This queue can deal with data wrapping aroundfrom the head to the tail. A queue can have one sender and one receiver;two such queues can be used for a request/response sequence, such as aninstance of the request queue on a system with a known name, and aninstance of a response queue per LSP process with a unique name. TheNamed Mutex can handle synchronization of access to the memory. To makethe request/response sequence synchronous, the requesting thread canwait for a signal from the response queue mutex when the response datais queued.

FIG. 21 shows multiple queues. FIG. 21 shows Winsock applications 2110and LSPs 2120, request queues 2130, response queues 2140, and secureapplication manager proxy 2150.

The memory mapped file regions and/or named mutexes can each require aknown name for access. Since a process running under the same account(or across the entire system on e.g. Win 9x) can access this memory ifthe name is known, an extra step can be designed in to make it moredifficult to access this memory. Known memory and mutex names that thesecure application manager exposes can be used to store the real memoryand mutexes names in encrypted format. The real memory and mutex namescan be based on random names generated at run-time, such as with thestrings ‘:Shared Memory’ and ‘:Mutex’ to denote their respectivefunctions.

The known shared memory regions names can be defined as follows:

<name>:AppProxy:StartupRequestQueue <name>:AppProxy:DnsRequestQueue<name>:AppProxy:PortmapRequestQueue <name>:AppProxy:Statistics<name>:AppProxy:AppTable <name>:AppProxy:FlowTable <name>:<communicationprotocol>:Pagelnformation

The names of the StartupResponsetQueue, DnsResponseQueue andPortmapResponseQueue can be random strings that can be generated atruntime and can be passed along with the request.

Once the secure application manager proxy reads the session cookie fromthe <communication protocol>:PageInformation region, it can erase thecookie so it is not always ‘hanging out’ in memory.

The following pseudo-code shows one way of how the secure applicationmanager proxy can read the session cookie from shared memory.

EnterReadLock( “<name>:<communication protocol>:PageInformation:Mutex”)OpenSharedMemory( “<name>:<communicationprotocol>:PageInformation:SharedMemory” ) EncryptedMemoryName =ReadEncryptedMemoryName( ) CloseSharedMemory( “<name>:<communicationprotocol>:PageInformation:SharedMemory” ) LeaveReadLock(“<name>:<communication protocol>:PageInformation:Mutex” )DecryptedMemoryName = Decrypt( EncryptedMemoryName ) EnterWriteLock(DecryptedMemoryName + “:Mutex” ) OpenSharedMemory( DecryptedMemoryName +“:SharedMemory” ) SessionCookie = ReadSessionCookie( )ClearSessionCookie CloseSharedMemory(DecryptedMemoryName +“:SharedMemory” ) LeaveWriteLock( DecryptedMemoryName + “:Mutex” )

The LSP can be installed onto the system like a normal clientapplication. If the LSP is installed from the Active-X download area,these files could be wiped out by Internet Explorer, leaving a brokennetwork configuration. Locked Files and Copy/Delete on reboot scenarioscan be dealt with like other client software installations. Oneembodiment's install packaging tool compresses the LSP related filesinto a self-extracting exe. This exe along with the two others can becab'ed for use with the Active-X downloader.

FIG. 22 shows an example of installation packaging. LSP, NSP, andsamsp.dll 2210, install script 2214, and MS redist Sporder.dll 2218, arecompressed into self-extracting .EXE samsp.exe 2220, which is cab'edinto samsp.cab 2230. SAMP Proxy samsvc.exe 2240 is cab'ed intosamsvc.cab 2260. SAM UI Samui.exe 2250 is cab'ed into samui.cab 2270.Titlebar Titlebar.exe 2280 is cab'ed into titlebar.cab 2290.

The following is one example of the operation of the secure applicationmanager. Various embodiments can add, subtract, rearrange, and/or modifyportions of the operation.

1. User selects the secure application manager on the intermediateserver generated web page

-   -   a. Active-X control downloads and installs LSP, NSP    -   b. Active-X control downloads and launches secure application        manager proxy    -   c. Secure application manager proxy retrieves configuration data        from intermediate server    -   d. If operating in destination mode, address/mask/port        combinations can be written to the redirect table

2. User launches new application, LSP, NSP load with process

-   -   a. Application issues StartupRequest from LSP to secure        application manager proxy to determine operating mode and/or if        this app should proxied or not.    -   b. If operating mode is application proxy and this application        is not in list, LSP can step out of process, NSP can ignore DNS        requests    -   c. Secure application manager user interface extracts icon from        application exe and adds to list in system tray

3. Application issues DNS lookup

-   -   a. NSP issues DNS request to secure application manager proxy    -   b. Secure application manager proxy issues DNS request to        intermediate server        -   i. If this is the intermediate server hostname issue local            DNS lookup, record address(es)    -   c. DNS response return along same path if any

4. Application issues connect to the IP address

-   -   a. LSP issues portmap request to secure application manager        proxy    -   b. If this application, associated destination hostname,        destination address/port are in the redirect table, then        establish port map, and return local address/port to LSP    -   c. LSP issues connection to address/port specified by secure        application manager proxy

5. Client application shutdowns connection and/or closes socket

-   -   a. Secure application manager proxy receives Winsock close        notification    -   b. Secure application manager proxy closes communication        protocol connection    -   c. Secure application manager proxy closes local portmap socket

6. Server closes connection

-   -   a. Secure application manager proxy receives communication        protocol close notification    -   b. Secure application manager proxy closes local portmap        connection and socket    -   c. Application gets normal Winsock close notification

7. Application exits

-   -   a. LSP Issues ApplicationCleanup message to secure application        manager proxy to remove current application from active list.

The user interface can include components such as the System Tray IconApplication and the Win32 Hook for displaying secure application managerstatus, such as in the title bar of each application.

Some embodiments feature one or more of the following in the end user'suser interface

1. End users can have the “Secure Client Applications” access mechanismin the intermediate server, only if they are allowed to, based on theintermediate server group based policies. The secure client applicationsaccess mechanism can launch a secure application manager (such as withActiveX) based session or a Java session manager, depending on theadministrator configuration for the subgroup. Some embodiments permitthe end user to the select, such as between Java v/s ActiveX basedsecure application access mechanisms, and others choose automaticallywithout user selection.

2. Users can select other intermediate server access mechanisms such asweb browsing, file browsing, telnet/ssh, etc., along with the secureapplication manager if these are enabled for the user's sub-group in theintermediate server. A secure application manager access mechanism canbe an additional access mechanism on the intermediate server.

3. The secure application manager client download can be of any size.Some embodiments take about 30 seconds or less over a dialup connection(such as 56 Kbps). Some embodiment of the secure application sessionmanager start in 1 minute or less before the user can start accessingenterprise applications.

4. The installation of secure application manager client can requiresome admin privileges to install the components. If the user does nothave the correct privileges, the user can be informed of the privilegesproblem. The user can be prompted to supply the correct administratorcredentials to install the secure application manager client components.

5. The secure application manager session manager can display statisticssuch as a list of client applications secured by the secure applicationmanager, and/or status for one or more of the client applicationssecured by the secure application manager. The list of clientapplications secured by the secure application manager can be anadministrator configured list of applications that need to be secured.The icons associated with these client applications can be displayed.These applications/icons can be selected (e.g., clicked) to launch asecured version of the client application. For one or more of the clientapplications secured by the secure application manager, the sessionmanager can provide a status, such as active (e.g., user launched theapplication) with optionally the number of sent/received bytes for thisapplication, inactive (e.g., application not yet launched), and error(e.g., error with the session).

6. The secure application manager session manager can run as abackground application under the same account privileges as the userthat launched the secure application manager. User can select (e.g.,click) the system tray icon to view the status of the secure applicationmanager session.

7. Session managers (e.g., client/server, secure application managersession manager, and/or network connect) can run as a backgroundapplication.

8. In the client, the secure application manager session on the sessionmanager can gracefully close (disconnect and/or terminate). Upon closingthe session manager, the secure application manager session manager canautomatically recover the machine to a clean state. In some cases themachine can be recovered to a clean state after the session managerexits, in other cases it is recovered to a clean state after the nexttime the machine is rebooted.

9. The session manager window can have an option to open an intermediateserver window.

10. When a user session times out, the intermediate server userexperience can be similar to Java session manager functionality. Thesecure application manager session manager can display a status such as“error” and there can be an option to restart the session. Selecting(e.g., clicking) restart session can, for example, open up a new browserfor the user to re-enter credentials. Once the user logs into theintermediate server, the secure application manager session can bere-launched. In some embodiments, the session manager can prompt theuser to re-type the credentials on the client side by opening up thelogin web page to the intermediate server. The user can continue theexisting application sessions without closing them.

11. Errors during the secure application manager client installation,session startup/recovery, and/or session failure can be reported in alog, such as Windows Event Log(Application Log) and/or in a custom userinterface log of the session manager.

Modules can log messages to a text file which can reside in the samedirectory as the LSP (e.g., %Program Files%\name\ApplicationProxy\samlog.txt). This log can be read and display, e.g., upon demandfrom the system tray application. Upon uninstallation, this log file canbe deleted.

An LSP can be upgraded in many ways. A current LSP can be locked intomemory and it can be impossible to overwrite it with a new versionwithout a reboot. To avoid this reboot, if the installer encounters alocked file, it can install a copy with a number appended to the end.For example if samsp.dll was locked, the install can write samsp1.dll tothe installation directory and update the Winsock catalog accordingly.The old dll can be flagged for a delete on reboot. Multiple differentversions of the LSP can be running at the same time inside differentapplications.

Interprocess communication message communication and shared memory tableheaders can contain version numbers for backwards compatibility betweenmodules. Downloaded, installed, and/or running modules can have versionnumber embedded in the binary file to determine when upgrades areneeded.

Much Windows desktop software is not known to be a secure environment,so the majority of the security enforcement can be performed on theintermediate server. Efforts can be made on the client side to preventusers from tunneling un-authorized applications into the secureenvironment. A couple examples of this are optional checksum lists forapplications and/or encrypting shared memory names to prevent malicioususers from intercepting the portmap request protocol.

Standard Win32 localization techniques can be used in the user interface(e.g., Unicode).

Because the connection can be initiated with a browser such as InternetExplorer, some embodiments are careful not to attempt to redirectInternet Explorer traffic destined for the intermediate server hostthrough the proxy. When the secure application manager proxy islaunched, it can retrieve the intermediate server hostname and/oraddress, e.g. from the Active-X control. When an application issues aDNS request to the intermediate server hostname, a local DNS lookup canbe performed, and the result returned to the application. The secureapplication manager proxy can then record the resulting address(es).When the application issues a connection to one of these addresses, someembodiments do not redirect this connection.

In order for the LSP to take affect and attach to a process, a newinstance of an application can be launched after the LSP is installedinto the protocol catalog. The intermediate server UI can warn the userof this. Some applications such as Internet Explorer may not alwayscreate a new process when a window is opened. An application launch iconcan be placed in the system tray application to launch Internet Explorerand ensure a new process is created

If the LSP was previously installed on the system, then an applicationmay not have to be restarted.

Some embodiments rely on an Active-X control which may function onlywith Internet Explorer based browsers. Other embodiments support otherbrowsers with e.g. a stand-along installation package. Some embodimentsuse Java or Netscape plug-ins to launch the modules.

Some embodiments support securing UDP and/or RAW IP traffic. When thesecure application manager is running in application proxy mode, some orall non-TCP traffic can be rejected by the LSP.

Most networked file systems are implemented with a file system driver inthe kernel and use the kernel based TDI interface for redirecting filesystem request to the network. This means that the LSP may not see thistraffic.

Microsoft has provided a Winsock-2 Transport Provider for NetBIOS. If anapplication were to use this transport provider, the LSP could see theNetBIOS traffic. However, Windows Explorer does not use this transportprovider for its NetBIOS usage.

Many embodiments have an LSP that interoperate with other LSP basedproducts. Any TCP based client server application will work with someembodiments of the secure application manager.

Port mapping the connections through loopback addresses is done by someembodiments for proxying the traffic. Network data makes an extra roundtrip from the from user space to the kernel and back. Certain Windowsservices bind to loopback addresses and ports in the kernel for whichWinsock has no knowledge of. The secure application manager proxy canthink it successfully bound to a loopback address and port yet neverreceive any connections or data because a kernel service intercepted therequest. One example of this is Microsoft remote desktop protocol takesover and controls 127.0.0.1:3389 without notifying Winsock.

Some embodiments create an interprocess communication interface betweenthe LSP and the secure application manager proxy for performing socketI/O. This can be implemented with a Winsock-2 Transport Provider copiesdata and events across to another process via interprocesscommunication. The LSP can then act as a switch redirecting applicationssecured by secure application manager to the new Transport Provider.

The secure application manager can support web browsers such as InternetExplorer, Netscape, Opera, etc. Some embodiments use Java or Netscapeplugging to launch native Win32 applications from a web-page.

A TDI hook driver can allow the capture and redirection of some or allNetBIOS traffic.

The communication protocol can support UDP based applications. The LSPand secure application manager proxy can e.g., use ‘UDP Associate’command to setup UDP flows between the two.

The communication protocol protocols can support incoming TCPconnections. The LSP and secure application manager proxy can use a‘bind’ command to setup up an incoming connection from the proxy to theapplication.

SOCKS can support for UDP and incoming TCP connections. SOCKS can besupported in some embodiments.

Once the Active-X control is downloaded and installed onto the systemfor network connect or secure application manager, a web-site can scriptthe control to download and run .exe's from their own server. Somecontrols deal with this issue by site locking the control, such as byrestricting it to run from a specific host or domain(s).

Some embodiments have a handshake between the control and theintermediate server to validate that this is being scripted from a realintermediate server.

Some embodiments perform one or more of the following. The followinglist elements can be modified, rearranged, added to, and/or removed.

1. A client can log into an intermediate server from a web browser. Forthis client, an intermediate server administrator can enable theintermediate server feature for accessing an application, such as an SAPclient for the sake of illustration, using the intermediate server groupbased policies.

2. A selection from the client to start a session can launch the secureapplication manager session from the intermediate server menu.

3. A secure application manager client (which can be an ActiveX control)can be downloaded that installs an LSP service on the client machine. Anew application that is launched on the client machine can be loadedwith the LSP service. The secure application manager client can also runas a process in the system tray. As explained above, a session managercan secure some or all traffic intercepted by the LSP service for theconfigured applications. In addition the session manager can display thestatus of some or every active secure application manager session.

4. A user can launch a client application e.g., SAP client, to connectto an enterprise SAP application resource.

5. When the client tries to connect to a resource, such assapserv1.mycompany.com, the call is intercepted by the NSP service.

6. The NSP service can then forward the hostname to the intermediateserver over the communication protocol.

7. The secure application manager daemon (protocol connector service)which can run in the intermediate server, resolves the hostname,sapsrv1.mycompany.com, in the intranet and returns the response back tothe secure application manager client.

8. The secure application manager client based on a successful“resolved” response from the intermediate server, can automaticallyconfigure a port forwarding channel, for example by auto provisioning ofan available loopback address such as 127.0.0.9.

9. The secure application manager client can then return the loopbackaddress to the application.

Some embodiments support one or more of the following: staticclient/server applications; dynamic and/or multiple port TCP basedclient/server applications; specification of a list of destination hostnames, client port and/or server port for specific client/serverapplications; client/server port forwarding; integration with clientsmaking superfluous specification of ports, destination host addressesetc.; one or more applications and/or destination hosts on a single portand/or multiple ports; client/server applications include serverinitiated connections (e.g., Active FTP) and/or client initiatedapplications; TCP and/or UDP based client/server applications;enterprise streaming resources such as Windows Media, Real, Quicktime,including live streaming; and enterprise real-time collaborationapplications and/or e-Learning resources (such as Netmeeting, Sametimeaudio/video etc.).

The secure application manager can scale, for example supporting, forexample, at least 500 or 1000 concurrent users.

Some embodiments have secure messaging, such as secure MAPI and/or Lotusnotes.

Some embodiments secure client/server applications, such as static portclient/server applications.

Some embodiments of the secure applications manager securing some or allclient/server applications that use TCP, and some or all connections areinitiated from the client.

Some embodiments have clustering support, such as handling sessiontimeouts and/or simultaneously handling other intermediate server accessmechanisms. LSP service can automatically choose to ignore the trafficintended for an intermediate server host (IP address of the host wheresecure application manager is downloaded from) even when IE isconfigured to be an application to be secured via the secure applicationmanager.

Some embodiments have support for UDP based applications, and/or the useof a protocol such as SOCKSV5 instead of or in addition to thecommunication protocol.

Some embodiments have support for TCP based applications that caninclude server initiated connections, such as FTP. A protocol such asSOCKS V5 can be used instead of or in addition to the communicationprotocol.

Some embodiments have integration with third-party vendors, such asvirus scanning and/or end point security products.

One example for the need for incoming TCP connections is to support FTPn active mode, which can be the default mode in most implementations.This can be referred to a client application on the client machine. Whenapplications listens on a socket, it makes a call to the winsock APIfunction listen( ). Inside the LSP; this call can be intercepted. Arequest is made to the local SAM proxy, referred to as a ‘bind request’.A bind request includes an IP address and port that the client machineis bound to. The local SAM proxy in turn can make a bind request to theintermediate server which can allocate an IP address and port on theremote network, the port being the one specified by the clientapplication on the local client machine. The intermediate server canlisten for incoming connections on the newly allocate address/port. Whena connection arrives, an incoming connection request is sent back to thelocal SAM proxy on the client machine, which in turns can forward theconnection request to the actual address and port the client applicationwas listening on. Incoming data from the remote network on thisaddress/port (socket) can then be forwarded back to the client's clientapplication and vice-versa. If the client application on the localclient machine closes the TCP connection, the SAM proxy can send aconnection close message to the intermediate server to tear down theconnection.

If the client application on the remote network closes the TCPconnection, the intermediate server can send a connection close messageto the SAM proxy on the local machine, which can in turn tear down theTCP connection back to the server application on the local clientmachine.

If the client application on the client machine closes the socket it waslistening on, the layered service provider can send a ‘bind close’message to the secuare application manager proxy which in turn canforward the request to the intermediate server to stop listening on thataddress and port.

UDP applications can be real-time multi-media applications suchreal-audio, cu-seeme, Voice over IP, etc. To support UDP in a genericmanner, UDP traffic should be initiated from the client. Otherembodiments support non-client initiated UDP traffic.

Inside the LSP, the WSPSend( ) and WSPSendTo( ) calls can be interceptedon UDP sockets. If this is the first UDP traffic seen on thisaddress/port, a ‘UDP Flow Request’ can be sent from the clientapplication to the local secure application manager proxy. The localsecure application manager proxy in turn can make a ‘UDP flow request’to the intermediate server. Once this is complete, the secureapplication manager proxy can allocate a local loopback address and UDPport for the client application. Inside the layered service provider,once the request has completed, the newly allocated address can besubstituted in the destination parameter for the WSPSendTo( ) call (orsendto( ) for winsock hook implementation); or during the WSPConnect( )call for a connected UDP socket API usage (connect( ) in Winsock hookimplementation).

The intermediate server can implement a UDP flow timer, if after acertain period of time, no UDP traffic is seen on the address and port,then it can tear down its ‘UDP flow’ client association. A UDP flowteardown message can then be sent back to the local secure applicationmanager proxy on the client machine which tears down its localassociation. No notification may be sent back to the client applicationdue the stateless nature of UDP. If the application send mores data tothe UDP address and port after the timeout period has expired, a new UDPflow request can be initiated. The UDP timeout period can be reset whendata is sent on the address and port.

FIG. 23 shows an example of applications and a transport driverinterface on a client computer on a local network. FIG. 23 shows asockets application 2310 and a NetBIOS application 2315. Transportdriver interface clients include sockets emulator 2330, NetBIOS emulator2334, and redirectors, servers, etc. 2338. Sockets interface 2320 isbetween the sockets application 2310 and the sockets emulator 2330.NetBIOS interface 2325 is between NetBIOS application 2315 and NetBIOSemulator 2334. Transport drivers (also called transport providers)include Appletalk transport driver 2350, NetBT transport driver 2352,Nbf transport driver 2354, TCP/IP transport driver 2356, and NWlinktransport driver 2358. The transport driver interface 2340 is betweenthe transport driver interface clients and the transport providers.

Some examples of kernel based TDI clients are NetBIOS, NFS, MS RemoteDesktop Protocol, and Microsoft Internet Information Server. TDI clientsmay use Winsock for name resolution, in which case the Winsock-2Namespace Provider can provide remote name service. Other networkapplications such as NetBIOS may perform additional functions such asbroadcast discovery and/or name lookups generated in the kernel, inwhich case these events can be trapped in the kernel and/or performcustom handling. Some embodiments can have one or more modes ofoperation. One mode can be a generic mode, where name lookup resultsperformed the Winsock Namespace provider can pass the results to thedriver for filtering and re-direction. Another mode can have customhandlers specific to an application or protocol.

FIG. 24 shows a generic operating mode. Shown are applications such asExplorer and ITS 2410, namespace provider 2420, TCP/IP TDI clients suchas NetBIOS and/or NFS 2430, TDI hook driver 2440, TCP/IP transportdriver 2450, secure application manager proxy 2460, and a remoteconnection towards the intermediate server 2470.

FIG. 25 shows a mode with custom handlers, similar to FIG. 24 butmissing the involvement of the namespace provider.

If an application is flagged on the server as a non-Winsock application,DNS lookups can be performed and/or the results passed to the TDI filterdriver. A loopback address and port can be opened by the proxy and alsopassed to the driver, so that it can modify the target address tore-direct its traffic to the intermediate server.

NetBIOS can be treated by a protocol specific handler because it doesnot only use DNS. It can perform broadcast discovery using WINS(directed UDP requests to server) and UDP broadcasts on the LAN. It maythen perform NetBIOS specific hostname resolution using WINS and/or UDPbroadcasts, followed by DNS. To support seamless integration intoMicrosoft Windows a protocol specific handler can perform networkdiscovery requests on the remote network. Even though NetBIOS can fallback to DNS after WINS and broadcast lookups custom name lookup handlingcan be performed. With custom name lookup handling, it will be moreefficient if NetBIOS name resolution is used as opposed to waiting fortimeouts and the fallback to DNS, and NetBIOS DNS resolution can beperformed by a system service that started before the secure applicationmanager was launched by the user, which can break the model of SAM.

The TDI Hook Driver can capture NetBIOS discovery requests, make copy ofrequests and pass to secure application manager proxy which can forwardto the intermediate server. Results returned from the intermediateserver can be retransmitted locally for the client to discover results.

The intermediate server can require a special protocol handler tosupport broadcast discovery and/or NetBIOS name lookups. The handler canperform typical NetBIOS tasks on behalf of the remote client, and/orreturn the results over the secure link.

The following is one example with NetBIOS. Steps can be added, removed,rearranged, and/or modified.

1. Administrator configures NetBIOS hosts and/or addresses to beaccessed remotely

2. User logs in, configuration is sent to client

3. TDI hook driver loads

4. Secure application manager proxy loads, opens I/O channel to driver

5. User issues request to open network share by NetBIOS name

6. TDI hook driver detects directed WINS query on known NetBIOS ports orbroadcast request

7. TDI hook driver consumes request and passes to proxy via ioct1

8. Proxy runs hostname through filtering process; if match found,NetBIOS name lookup forwarded to NetBIOS name service handler onintermediate server. If match not found, request is retransmitted onlocal network for normal operation.

9. Intermediate server performs WINS and/or broadcast name lookupdepending on remote network configuration.

10. Proxy receives NetBIOS name lookup responses

-   -   a. Opens loopback address and port for redirection    -   b. Passes real IP address, port+loopback IP address and port TDI        filter driver.    -   c. Retransmits name lookup result to client application

11. TDI filter detects NetBIOS traffic on resulting destination IPaddress

12. TDI filter replaces destination IP address with assigned loopbackaddress and port, as a result the TCP/IP stack transmits the data to thesecure application manager proxy

13. Proxy forwards NetBIOS to intermediate server

FIG. 26 shows a method embodiment. In 2610, a network connection requestis received. In 2620, the network connection request is redirected. In2630, data are sent towards the intermediate server. The method canpermit secure remote access to the remote network.

The network connection request can be received on a computer on a localnetwork. The network connection request can be initiated by a clientapplication of a client-server application. The client application canbe on the computer. The network connection request can include adestination on a remote network. A server application of theclient-server application can be on the remote network.

The network connection request can be redirected within a Windows socketlayer on the computer. This can include redirecting the networkconnection request with the namespace provider (e.g., utilized fordomain name service lookups on the remote network) and the layeredservice provider (e.g., utilized for redirecting the data of the clientapplication from the local network to the remote network). The networkconnection request can be redirected away from a transport serviceprovider (e.g., a TCP/IP transport service provider) of the computer.The network connection request can be redirected to an intermediateserver in the remote network. The intermediate server can perform thenetwork connection request on behalf of the computer. The redirectingcan be based on one or more of: a name of the client application, achecksum of the client application, a version of the client application,a server of the destination, and a port of the destination. Prior to theredirecting, the network request can pass through one or more of theWinsock dynamic link library and the Winsock 2 dynamic link library. Thenetwork connection request can be redirected to the intermediate serverin the remote network via at least a proxy on the computer.

The data of the client application can be sent from the computer towardsthe intermediate server. A secure sockets layer (SSL) can encryptcommunication between the computer and the intermediate server. The dataof the client application can be sent from the intermediate servertowards the server application. Various embodiments send the data of theclient application from the intermediate server towards the serverapplication, or allow this to occur by software or hardware outside ofthe embodiment. The data of the client application can be sent throughat least a local address and a local port of the computer prior tosending the data of the client application towards the intermediateserver.

In some embodiments, a visual cue can be provided to indicate a secureconnection between the client application and the intermediate server.The namespace provider and the layered service provider can beautomatically installed on the computer and/or uninstalled from thecomputer.

FIG. 27 shows another method embodiment. In 2710, a network connectionrequest is received. In 2720, the network connection request isredirected. In 2730, data are received from the intermediate server. Themethod can permit secure remote access to the remote network.

The network connection request can be received on a computer on a localnetwork. The network connection request can be initiated to a filesystem on a remote network. The network connection request can include aname of the file system.

The network connection request can be redirected using a transportdriver interface on the computer, and may further use a namespaceprovider. The redirecting can capture network file system traffic. Thenetwork connection request can be redirected away from a transportdriver (e.g., a TCP/IP transport driver) on the computer. The networkconnection request can be redirected to an intermediate server in theremote network. The intermediate server performs the network connectionrequest on behalf of the computer. The redirecting is based on one ormore of: a destination server and a destination port. Prior to theredirecting, the network connection request can pass through at least atransport driver interface filter.

At the computer data of the file system from the intermediate server canbe received. A secure sockets layer (SSL) can encrypt communicationbetween the computer and the intermediate server. The data of the filesystem can be transferred between the intermediate server and the filesystem on the remote network. Various embodiments transfer the data ofthe file system between the intermediate server and the file system, orallow this happen via hardware or software outside of the embodiment.

In some embodiments, the transport driver interface can be automaticallyinstalled on the computer and/or uninstalled from the computer.

The various aspects, features, embodiments or implementations of someembodiments described above can be used alone or in variouscombinations.

Some embodiments can be implemented in software, but can be implementedin hardware or a combination of hardware and software. Some embodimentsof the invention can also be embodied as computer readable code on acomputer readable medium. The computer readable medium is any datastorage device that can store data which can thereafter be read by acomputer system. Examples of the computer readable medium includeread-only memory, random-access memory, CD-ROMs, DVDs, magnetic tape,optical data storage devices, and carrier waves. The computer readablemedium can also be distributed over network-coupled computer systems sothat the computer readable code is stored and executed in a distributedfashion.

The advantages of some embodiments are numerous. Different embodimentsor implementations may yield one or more of the following advantages.One advantage of some embodiments is that an intermediary server can beinterposed between remote servers and clients to facilitate secureaccess. Another advantage of some embodiments is that content requestedby clients can be altered to direct subsequent client requests to anintermediary server which, in turn, acquires the requested content forthe clients. Still another advantage of some embodiments is that anintermediary server can authenticate requestors seeking access toresources on private networks through use of native authenticationprovided by the private network. Yet still another advantage of someembodiments is that secure remote access to private networks can easilybe provided for authorized persons at reasonable costs.

The many features and advantages of some embodiments are apparent fromthe written description and, thus, it is intended by the appended claimsto cover all such features and advantages of some embodiments of theinvention. Further, since numerous modifications and changes willreadily occur to those skilled in the art, it is not desired to limitthe invention to the exact construction and operation as illustrated anddescribed. Hence, all suitable modifications and equivalents may beresorted to as falling within the scope of the invention.

1-39. (canceled)
 40. A method comprising: generating a networkconnection request at a computer on a first network, the networkconnection request indicating a destination server on a second network;redirecting the network connection request within a namespace provideror a layered service provider of a socket layer on the computer, thenetwork connection request being redirected away from a transportservice provider of the computer to an intermediate server in the secondnetwork; and sending data from the computer towards the intermediateserver, where the data is sent from the intermediate server toward thedestination server when a connection is provided between the computerand the destination server.
 41. The method of claim 40, where thelayered service provider is utilized for redirecting the data of theclient application from the first network to the second network.
 42. Themethod of claim 40, where the namespace provider is utilized for domainname service lookups on the second network.
 43. The method of claim 40,where the transport service provider includes a TCI/IP transport serviceprovider.
 44. The method of claim 40, further comprising: encrypting thedata sent between the computer and the intermediate server.
 45. Themethod of claim 40, further comprising: providing an indication when theconnection is a secure connection.
 46. The method of claim 45, where theindication is a visual indication.
 47. A system comprising: a processorto: receive a network connection request on a computer, the networkconnection request corresponding to a remote network, the networkconnection request including a name of a destination device on theremote network; redirect the network connection request away from atransport driver on the computer, the network connection request beingredirected to an intermediate server in the remote network; and receive,at the computer, data of the destination device from the intermediateserver when a connection is provided between the computer and thedestination device, where the data of the destination device istransferred between the intermediate server and the destination deviceon the remote network.
 48. The system of claim 47, where the processoris further to: pass the network connection request through a transportdriver interface filter prior to the redirecting.
 49. The system ofclaim 47, where the transport driver includes a TCI/IP transport driver.50. The system of claim 47, where the processor is further to: encryptthe data.
 51. The system of claim 47, where the processor is further to:redirect the network connection request based on a destination server ora destination port.
 52. The system of claim 47, where the processor isfurther to: automatically install a transport driver interface on thecomputer.
 53. The system of claim 47, where the processor is further to:automatically uninstall a transport driver interface from the computer.54. A computer-readable memory device including instructions forperforming a method for network communication, the method comprising:generating a network connection request at a computer on a firstnetwork, the network connection request indicating a destination serveron a second network; redirecting the network connection request within anamespace provider or a layered service provider of a socket layer onthe computer, the network connection request being redirected away froma transport service provider interface of the computer to anintermediate server in the second network; and sending data from thecomputer towards the intermediate server, where the data is sent fromthe intermediate server toward the destination server when a connectionis provided between the computer and the destination server in responseto the network connection request.
 55. The computer-readable memorydevice of claim 54, where the layered service provider is utilized forredirecting the data from the first network to the second network. 56.The computer-readable memory device of claim 54, where the namespaceprovider is utilized for domain name service lookups on the secondnetwork.
 57. The computer-readable memory device of claim 54, where thetransport service provider interface includes a TCI/IP transport serviceprovider interface.
 58. The computer-readable memory device of claim 54,where the method further comprises: encrypting the data sent between thecomputer and the intermediate server.
 59. The computer-readable memorydevice of claim 54, where the method further comprises: providing avisual indication when the connection is a secure connection.